That's an argument to never ever try to upgrade, because there is always some overlap in this kind of transfer. Not quite the same as "it's pointless to build another refinery because it won't be finished for ten years", but similar. Good to see in the next paragraph that he came around to reality.
I am looking forward to the day when I go to a new doctor for whatever reason (emergency, out of my usual area, opportunity) and having them type my name into their computer and seeing my last five years of medical information instead of having to fill out a five-page "new patient" form.
They need to go back further than 5 yrs unless that is how old you are. All my health records from the 70’s on are LOST. Some of those from the 90’s are now needed and can’t be found either. DUMBO was supposed to fix that.
I know this is a long post, but it is for the benefit of some who might not realize the scope of what they have to do in order to bring this new Cerner EMR system online.
This is a huge endeavor and needs doing, but the thought of this is daunting. I do these kinds of migrations for a living, and they are always painful.
Always. And while the systems I have helped migrate may have millions of patients, studies and histories, the VA one is far, FAR larger and the systems (new and old) are likely just as disparate.
Additionally, the problem is not confined to simply figuring out what data points are in the old system, matching where those same data points belong in the new system, finding a way to export from the old into the new, and voila, you’re done!
Sure, there are things like PATIENT NAME, DOB, SEX, etc. that are always going to be present in some form in two systems, but even in two relatively modern systems, SEX may be three values “M”, “F”, “U” in your current system, but the new system may store values of 1, 2, 2, 3,4, or 5, and you may have to translate those M, F, U values into the new systems value that says the same thing. I have even seen old systems that had people free texting things in, and you saw things like M, Male, Man, etc. Those all have to be translated.
In many cases, the new system has capabilities that need data points (because it is NEWER and ostensibly has more capability) and in some cases, there may be not data points in the old system, so there is no flag. If it is a mandatory field, you have to do an exercise to see if an proxy value can be developed from the old data, and if not you figure out the least intrusive value to put in there so the field is populated and then update it with new data going forward as patients are processed through.
And there are even other cases where the new system doesn’t have the capability of the older system. So you have to do a gap analysis, study the capability of the new system, and compare it on a point by point basis. Which involves doing intricate work flow analysis, with flow charts and such to make an accurate evaluation and comparison. We had one such system had such a long and intricate workflow the analysis went to 10 pages, with arrows leading off the edge saying “Got to page 6” and such, and we never finished it. We got to the point we decided we were going to have to keep that old mainframe system running for a variety of reasons, and that function was one of them.
I remember many years ago we were evaluating transitioning a very old mammography system from the DOS system it ran on to Windows. We did the exercise to getting all the fields available, and comparing them. We found out the Old system had far more fields than the new system, which we thought might be preferable, but it involved long conversations with the developers who who actually wrote the code, asking questions like “What does this value here do in YOUR program? Armed with that information, you talk to the software developers at the NEW product, and they are baffled. “We don’t do to that way, we use thee flags with three data points to do that same function in our system, and we can’t use that point...”
Bottom line: we ended up running the two systems in tandem for a long time, because there was no other alternative. In these types of things, sometimes there simply is no alternative, because the political or patient care ramifications rule them out.
And so on.
New isn’t always better. Well, if that is the case, why not stick with what you have and improve it? That is usually an option to evaluate, but many 10-30 year old systems have reached certain structural/database limits, cannot be protected from malware, cannot have the software upgraded any further...basically, you just reach the end of the road.
And then you have to do data migrations themselves, all don in a dynamic environment where patients are having things done every single day, and those migrations cover labs, radiology, patient notes, audit trails, pathology, appointments, cancels, which all need their own complicated migrations done.
And this doesn’t even take into account how putting in this new system interacts with other systems. You may have had a nice integration where when you opened the medical record of a patient and looked at an X-ray result in your medical record, that It automatically opened the images for viewing too. You have to maintain the same function, if you can’t outright improve it, which is what people expect.
I am fully on board with clinicians and patients who don’t like the modern concept of Electronic Medical Records (EMR). It turns high powered clinicians and doctors into data entry people, and often makes patients wait longer. But they do have their clinical upsides if done correctly, and in today’s litigious environment, being able to force people to capture a data point with a forced question has value, as does the IT aspect of being able to easily patch it to keep it protected from current threats.
It is a huge job, and I is going to cost the taxpayers a lot of money. But if we have to do it to improve care to our veterans...we have to do it.
The scope of it does make me a bit queasy, though.