Archive for EHR 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).

What Would MacGyver Do?

Sometimes you just have to “MacGyver” a situation. I find that to be true in pretty much every aspect of life, whether I’m working on a medical data integration project or something closer to home.

While moving into a house that was new (to us), we unpacked several boxes of dishes and put them in the dishwasher that was several years old. We loaded up the bottom tray and had the majority of the top tray loaded when it happened. Three of the four wheels that suspend the top tray in the dishwasher fell off. Luckily, my wife caught the side that fell off completely until I could grab it and we could unload the tray.

I spent several minutes thinking “CRAP! We’re just moving in and stuff is already falling apart.” I accept the fact that unexpected expenses show up, and sometimes at the worst time. I’ll have more to say about that in another post. What I want to focus on now, is how you react to things that happen around you.

In this instance, our options were limited. It was late, we didn’t have many tools, and we couldn’t fabricate new plastic wheels. I was going to have to “MacGyver” a solution. Do we have gum and a paperclip? (What MacGyver always seemed to use to get out of a precarious situation.) No. What we did find was a bundle of twist ties. I grabbed three of the longest ones and attached the wheels back on the tray. A little weight test, and it seemed to work. We put some dishes in the tray and it still held. We ran the dishwasher and didn’t hear any big crashes. Everything seemed to work.

In this case, I took a little time for some self pity and panic. But that really didn’t get me anywhere. You have to get up, dust your wheels off, assess the situation, and engineer a solution that works in that moment.

In the world of EMR integration, we get involved in many conversations where the prospective client has already been told that there is no solution to their business challenge. Sometimes they’ve been told that more than once. Most of the time it is an EMR vendor that is not willing to customize an integration solution to meet or even understand their requirement. I know that unique solutions can greatly hinder supportability across thousands of clients. But if the client cannot succeed using a particular application, they will eventually find a software solution that will better facilitate their business.

We just finished up an integration project for a client that had already been told that what they wanted couldn’t be done. They need an outbound diagnostic imaging orders interface to a PACS system. That’s not all that unique. What is unique about their requirement is the return inbound results. The inbound messages either get routed as transcription, populating different sections of an existing progress note or back to the order notes, depending on a value in the HL7 message.

Don’t get me wrong. There are times when there are too many barriers to engineer a proper solution, but dismissing the challenge before you open your mind to the possibilities does not serve you or your client. Think of related activities that can be done. How are those activities related? Can you string a set of related activities together to get the desired outcome? A little creative thinking can go a long way to creating a pretty crafty solution.

Were you looking for an article on EHR integration, or for a crack team of wizards who can work wonders? Either way, you’re in luck. You’ve found both. Mi7 offers top-tier services related to medical data and making the best use of it. Don’t let anyone tell you it’s impossible until you talk with us.


My wife and I were driving to work this morning and the song “Magic” by PILOT came on the radio. We looked at each other and chuckled. We both work in the IT industry, providing solutions for medical practices. Our work with EMR systems and data integration requires specialized knowledge, making us look like magicians to our customers. Of course, it’s not magic at all. We follow a proven process and our customer is part of that process.

There are two types of customers out there.  The first type of customer is one who doesn’t care about the difficulty of the project or the time frame; they just want it to immediately be “magically” done.  The second type of customer realizes that the project really isn’t magic and that it actually takes a considerable amount of time and effort to make it seem like magic.

As with any project, the expectations you bring to the table are important. A successful integration project depends on our customer, no matter which type of customer they are, being involved in the business decisions from the beginning to go-live. They stay involved in the daily operation and support of the integration. I’m not saying that a doctor needs to support their own interface, but someone at the practice should monitor and reconcile messages daily to know if the interface worked that day and report any issues to support.

Let’s demystify data integration projects from the thousand foot view. Just like any development project, there are several steps.

  1. Scoping – Defining the requirements for the integration. This includes the business and system processes on both sides of the interface, data that will be sent and received, and how the data will be handled when received. It is important for the customer to be involved in this process so that they identify their business needs and know how the interface will work when completed.

  1. Development/Configuration – No matter if this is a “standard” HL7 interface or not, there is always development and/or configuration. Depending on how “custom” the business process is that the interface is facilitating, the development could potentially be more complex and take longer.  The customer may not be involved in the development, but the implementers may have questions about different scenarios and use cases, so it is important for the customer to stay engaged in the conversation.

  1. Testing – Vendors involved in implementation of an interface usually do round-trip 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 that each of the business scenarios is working as expected.  Make sure you devote ample time to testing; it will save you headaches in the long run.

  1. Go-live, On-going Reconciliation, and Support – Once the integration has been tested, it can be put into production. The work doesn’t stop once in production. The client needs to monitor the interface to make sure it continues running as expected and determine if any business scenarios that were not tested or new business scenarios are handled properly.  There will also likely be some data issues, like unmatched patients or encounters, that need to be handled through a reconciliation process. Of course if you have any questions or issues you cannot resolve with the tools provided, call your vendor for support.

These four steps are the basic highlights. The details differ from one practice to another, depending on the nature and scale of the project. I’ll devote some time later to each one of these sections individually.

But for now, remember these three things:

  • Be present.
  • Ask questions if you don’t understand.
  • It’s your system. Your data. Own it.

It’s magic, you know… Never believe it’s not so…

By the way, you may have been looking for an article on EHR integration services for hospitals and medical practices. In case you didn’t know it, this is it. I just didn’t feel like peppering it with fancy words and stuffy keywords.