Archive for Data Integration

Feelin’ Lucky With Your Data Migration or Integration Project?

My wife and I recently went to the home of Ernest Hemingway in Key West. Learning about the history of the house and some of the background of the books by Mr. Hemingway, I decided to read some of Mr. Hemingway’s work. I started with The Old Man and The Sea.

For those of you who have not read this wonderful, short, piece of literature, I won’t ruin the story for you. I will just give you a synopsis of the story here so we can get to the point.

The story is located in and off the shores of Cuba (also Mr. Hemingway’s origin). There was an old man. He was a fisherman. He hadn’t had much luck with the fish lately. One day he went out alone on his small fishing boat. There is one quote that I want to focus on for this blog. The old man says it to himself several hours after he set out on the boat.

“Every day is a new day. It is better to be lucky. But I would rather be exact. Then when luck comes you are ready.”

I think this quote especially applies to system testing. In the “Magic!” blog, we discussed the process of integration projects:

Vendors involved in implementation of an interface usually do roundtrip testing (to verify communication) and basic test cases. The responsibility for the more rigorous testing typically falls to the client. This is what is called user testing. The client needs to outline the different business scenarios that the interface was designed to solve and develop test cases that will verify all of the business scenarios. Make sure you devote ample time to testing. It will save you headaches in the long run.

Let’s break this down further.

What is roundtrip testing? For each type of message (demographics/ADT, scheduling/SIU, charge/DFT, etc), the sending side of an interface will send a message. The receiving side will verify receipt and verify the message is formatted as expected (see “Standard is not so Standard” for more discussion of setting expectations). Note that this is more to confirm that the two systems are talking rather than to verify any sort of business logic.

Why do most vendors only do roundtrip testing? Most vendors will not know the workflow intricacies of a practice. The vendor knows what is in the specification document for the integration. They can test what is outlined in the specification, but what is outline in the specification does not necessarily encompass all variations in workflow practice encounters, especially rare scenarios. The vendor relies on the practice to know their workflow and to understand the different scenarios that need to be tested in the integration. This is not always the case. For example, the practice may have a couple patients that come in once or twice a year. These patients are special cases and the practice may need to have a special workflow in their system for these two patients when they visit. An integration built for the standard use case that covers 95% of all encounters may not properly handle the special cases in your practice.

It is the practice’s responsibility to identify these special use cases and test for them. When I discuss testing with a client I ask them to first describe the typical workflow. For example, we have a client that implemented a demographics interface from an associated hospital. The typical workflow for a patient that doesn’t exist in their system is to add the patient, add the guarantor, and add the patient insurance. The typical workflow for a patient that does exist matched on account number, first name, last name, and date of birth is to just update demographic information, leave the guarantor as is, document the patient insurance in the demographic notes, but don’t update the patient insurance on the patient.

Once you have described the typical workflow, start going through the possible variations of the workflow. You need to include knowledgeable people from all departments that are affected by the interface to catch the possible different scenarios. In our example, as we were testing, we found a special scenario where a patient was admitted to the hospital ER, but the new account entered in the hospital system had a temporary patient name. Well, this prompted a message across the interface with the temporary name. This name was entered in the receiving system side as a new patient. When the name was updated, we got a mismatch because the account number matched, but the patient name and date of birth did not. This prompted us to change the scope and logic of the interface on receiving side to discard patients with certain specified names and departments. Once all of the information was filled out, we would then enter the patient on the receiving side.

It is always better to understand these different scenarios when you are scoping out the integration project, but if the practice does not catch the scenario in testing, it can cause bigger data issues in production. In the example, not testing all of the scenarios could have resulted in lots of incorrectly entered and mismatched patients when the interface was put into production.

Another important point with testing is to test everything every time there is a revision. If you caught an error in one of your testing scenarios, make sure to test every step in all of your scenarios again when the error is resolved by the interface vendor. There have been many times when I am testing for a client that when the vendor fixes one thing it breaks something else. The fix had unintended impact on a different part of the integration process. Start from the beginning. Test every scenario thoroughly with every revision. You may even find that other scenarios come up when you find an error that you need to test specifically to make sure the previous error does not rear its ugly head again.

A practice should realize the system is theirs. Accepting what happens to you after the fact is never a good position to take. The practice is the last line of defense before a system or interface is implemented that could benefit or harm the practice. Test it. Understand it. Even if project scope needs to change, it is best to catch an issue up front before your practice is reliant on the system and has to implement work-arounds to accomplish their goal. You may realize that it costs more in the long run to allow things to happen without testing than to put the effort in up front and make the system work as you need it. As the quote said, you might get lucky, but it is better to be exact. It is better to be prepared. Then you will be ready if you are lucky.

Is your practice planning a data migration or integration project, and relying on luck to get you through it? Don’t do it! Luck will only get you so far. It will probably not catch you a fish, and most certainly won’t lead to a successful data migration for your medical practice or physician organization. Migrating data from one electronic health records system to the next takes careful planning and testing. Rely on the data migration gurus at Mi7 to put you on the right path. We’re not lucky, we’re exact. And that’s the way (uh-huh uh-huh) we like it (uh-huh uh-huh).

The Wheels on the Bus Go ‘Round

We were driving from St. Louis to Chicago on a Sunday afternoon for an appointment Monday morning.  When we were about an hour and a half outside of Chicago, our tire blew.  We were close to an exit, so I pulled off the highway and into a truck stop to assess the situation.  We have these run flat tires that allow you to go 50 miles at 50 mph.  We had more than 50 miles to go to our destination and I didn’t feel comfortable driving 50 mph on an interstate where people were going 80+ mph, so I assessed the situation. 

We needed a new tire.  Can we get a new tire somewhere close? Nope.  Many of the tire stores in the area were closed since it was late Sunday afternoon.  The big tire stores (Walmart and Sears) didn’t carry the tire we needed and would have to order it.  We had to be towed to the dealer in Chicago, so I called roadside assist.

I had two passengers with me, so I knew that riding in a standard tow truck was not going to work.  I requested a tow with 3 passenger ride along. I was given a 2 hour ETA.  I got a call from the contracted towing company about 40 minutes later.  I confirmed that there was room for 3 passengers.  Unfortunately, this was not communicated to the towing contractor, so the truck that was in the area did not have the room for 3 passengers.  This prompted another call to roadside assist and a new towing company dispatched a truck for us.  

This is not the end of this story, but it is enough for this post.  I relay this story because sometimes things get lost in translation.  It’s like when you played telephone as a kid.  You tell someone something, they tell someone else and so on.  By the end, what is being said may not be the same as what you told the first person.  

How does this apply to healthcare technology?  Many practices have seen the value  of in-house lab and imaging equipment for their business.  They can offer these services internally instead of referring the patients out to other businesses.  The issue is that not all lab and imaging devices can speak the same language as the practice’s EMR.  Sometimes the devices only communicate via serial or network via ASTM,  ABX, or Argos.  Sometimes the EMR will only accept HL7.  Mi7 has developed the expertise to take the device languages and translate the data to HL7 or, in some EMR’s, write the data directly to the EMR.   With the government incentives and mandates to store discrete data (test results as individual values), practices have been printing out these results and manually entering them.  This can reduce employee productivity and introduce potential errors to the result transcription process.  

I have seen practices take the data from these machines and create proactive marketing (called “health maintenance” programs in the patient arena) campaigns to promote patient maintenance of A1C, Cholesterol, and other key chronic maintenance values.  This helps the practices pay for the device and improve overall patient health.

There are many types of devices that collect and report on data.  If you are paying for the device, why not use the data provided by the device to improve patient care and potentially grow your business? Use the devices you have.  Maximize the value of data collected by these devices. It’s your data. Use it.

What a brat! Data Ownership and EHR Vendors

Do you recall sharing when you were a kid? I don’t necessarily remember the sharing specifically, but I remember the times I didn’t share and got punished for it. I now hear kids yelling “MINE!” when asked to share a toy and I think … What a brat!

I have the same thought when I speak with practices that are experiencing migration problems. They are trying to get data from their EHR and the EHR vendor keeps throwing up roadblocks. While many EHR vendors have the philosophy that data stored in their system is theirs, the law states something different. Many states have laws concerning the ownership of patient health record data.

A minority of states side with the patient. The majority don’t have laws governing the ownership of data. The rest side with the hospital, practice, or health care professional that generates or maintains the chart.

In none of these state laws does it say that the data is owned by the EHR vendor. The discussion of data ownership between the EHR vendor and the health care professional is a contractual discussion. The EHR vendor does not own the data. They may have contractual use rights authorized through the business associate agreement or contract, but they do not own the data.

The reality is that the EHR vendors are the gatekeepers to the data. They know where the data is, how it is organized, and how to get the data out. There are many horror stories of vendors holding data “hostage.” MINE! Many of these are due to contractual obligations (like outstanding balance issues) not being met by the healthcare professional. There are other instances where the contract between the EHR vendor and healthcare professional did not include data extraction provisions for when the contract was terminated. This is not the EHR vendor’s data.

Data belongs to the patient, the hospital, or healthcare professionals. The trouble is this; many times when practices attempt to take control of their data, they ask questions of the EHR vendor and get the MINE! response. It is time we stop asking for data and start demanding our data.

At HIMSS16, many of the discussions were around INTEROPERABILITY. This means sharing of data between systems. One of the biggest INTEROPERABILITY challenges is when a provider moves from one EHR vendor to another. Migrating discreet data (field by field) can be costly. A practice looking to move should prioritize the data that they want to migrate and evaluate how they are going to use the data. Try to put a dollar value to migrating that data. Then you can decide if the cost for migration is really worth the value you expect to receive. Many practices take a summary approach where they migrate clinical notes as documents instead of discreet data. Then they take the money they save there and use their prioritized list of data items to determine what they want to migrate (problem lists, allergies, histories, etc). This way the practice maximize the value of the data they migrate.

Another INTEROPERABILITY challenge is mining all of the data that is collected in the EHR software. Many EHR vendors provide reporting platforms for reporting on data, but most do not provide a true analytics platform where the healthcare professional can really analyze and manipulate the data to find trends and manage their patient population’s health. This means that if a healthcare professional does not have an analytics platform to do this analysis, a third party analytics package must be integrated with their EHR. Integrating EHR’s into analytics platforms can be a time consuming and costly job since some EHR’s do not provide mechanisms to regularly extract data or provide schemas for their database.

The healthcare professional has gone through major workflow changes and has worked many extra hours entering data (more than they did on paper) all with the expectation that this data can be used to either better treat patients or improve the profitability of a practice. Yet, after all of the time and money spent on implementing EHR’s, the data is many times “stuck” in the EHR. MINE!

Silence the MINE’s! Stand up and take control of your data! If your EHR vendor is not willing to provide your data for analysis or migration, find someone who will!

Recommendation: Next time you negotiate, or renegotiate, a contract with your EHR vendor, make sure you have rights to the data and a provision to get the data when the contract is terminated. If you are not able to get your data for analysis purposes from your EHR vendor, find a consultant that is experienced in that EHR to get the data for you.