Archive for Data Migration

Preparing for Discreet Data Extraction

All great initiatives start with a plan, a great deal of soul searching about exactly what it is you are trying to accomplish, and what you have at your disposal to work with. The process of discreet data extraction from your electronic health records system is no different. Having a plan and knowing what you have – and where you’re going – are critical. We at Mi7 have compiled a list of tips and things to consider as you prepare for your data extraction project:

  1. Do you have current processes in place for capturing your data?

Before we begin any extraction of data, it’s important that we know what processes you currently follow, and if your providers have guidelines for how data is entered. This will help us determine how clean and useful your data is, and what considerations we’ll need to account for as we plan for the extraction. For example, if there is no process in place to guide a provider to type in “ten” versus “10” into a data field, that inconsistent data will mean nothing to the system (the new one or the existing one), and will make mapping the data between system more challenging.

  1. How will you be using your data once extracted?

There are many reasons for extracting discreet data. You may be importing it into a new EHR, or archiving it. Regardless, your data extraction and the output we provide will be tailored for your specific needs. We’ll either prepare it for useful import into your new system, or provide easily searchable PDF documentation that can be used for archival purposes.

  1. What third-party systems will you need to integrate with?

This is important to know as we prepare your data to be useful in a new EMR environment. For example, if you are routinely interfacing with lab devices, we know that those devices like to receive data in more numeric format versus text.

  1. Will you be consolidating multiple systems?

Preparing to consolidate multiple systems requires a bit more thought and preparation, especially when identifying which fields will be migrated and the names of those fields. For example, “Are you a smoker” is a common piece of information to capture in your EMR. However, the field may be named something different across multiple systems. We’ll help you identify these fields and develop a plan to match them up.

  1. How do you want to view your data in the new system?

If you are moving to a new system, you have a choice of how you will see your data in the new system.  However, the detail to which you would like to view the data will affect the cost of the data extraction and import.  You can decide to simply have a summary document created that can be referred to when a new patient is documented in the new system.  Alternatively, you can decide to have individual discrete data point transferred over to the system.  We can assist you in discussion the costs and benefits of each option.

No matter your reasons for extracting discreet data, making sure the data is clean and consistent is the best way to prepare. If you need a discreet data extraction, contact Mi7 today! We have extensive experience, and can create custom solutions to fit your needs.

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).

Junk in the Trunk… and the Data Migration Process

We bought a car about a year and a half ago. Every time I switch cars, I have this feeling of “where did all of this crap come from?” It’s a car…I like to think I don’t store a bunch of stuff in my car, but when I start clearing out the trunk, the middle console, the glove compartment and all of the little door cubby holes, there ends up being a lot more than expected. I’m not a traveling salesman, I don’t work out of my car, and I don’t have kids. There shouldn’t be that much in there. When you start going through the stuff that needs to be transferred, there are a few pieces of paper (old insurance information, receipts, etc) that can be thrown out, but you ultimately believe that you need to move all of that stuff to the previously clean new or new to you car. That stuff can add up. I remember having three full shopping bags of stuff last year.

Switching EMR systems is a lot like switching cars or moving. There is a lot of planning involved, you have to move stuff from one place to another, there is a learning curve to the new car or place even though you have the basics down, and there may even be some buyer’s remorse (there probably will be at some point). I have been involved with hundreds of system switches. The biggest issue facing implementations is expectations. Typically car buyers do some research about the car they are buying. I’m not saying that EMR system buyers don’t do their research. It’s just that the expectations they have of the system and the implementation process don’t typically match reality.

A system buyer not only needs to have researched the system they are buying, but also the process for the switch. How exactly are you going to stop using one system and start using another? What is the process for training users? Will the practice be down for a period of time? What is the plan for getting data from my old system into another?

It is this last question that I want to focus on here. There are several moving parts to a data migration. You have the current system and how it is implemented, the current vendor, the new vendor, and the new system. Any one, or more, of these parts can put limitations on the data you can move from the old system into the new.

In the past few years, system vendors have started limiting the data they will provide when a client leaves to specific data formats. This means that you get what they will give you. Some vendors will still estimate a custom extract, but typically it is more cost effective to take what they will give you in the standard extract. When evaluating a custom extract, you really need to think about the cost benefit of getting the data you want that is not in the standard. I recommend getting the information about what data a system vendor will provide and costs as early on in the process as you can. You will probably get a shopping list of the different data you can get. This is good information to discuss with the vendor for the system to which you are switching.

When you talk to the vendor who is migrating data into your new system there are several things you want to understand. Below is a non-exhaustive list to get you started:

Data To Be Migrated
  • What data can they migrate into the new system in comparison to the data the current system vendor provides?
  • What is this data going to look like in the new system?
  • Will the migrated data be reportable?
  • Will there be a test migration so that you can evaluate the data migrated?
  • If there is a test migration, will anything be erased or overwritten when the production migration is run?
  • Does the data need to be pulled from the current systems multiple times?
  • Will there be a staggered go-live so that different groups of patients need to be migrated at different times?
  • Will there be downtime in the old or new system for the migration?
  • Will there be a period of time in which you’ll have to track data in both systems? In other words, after the data is extracted from the current system, will you need to track any data changes in the current system and enter them manually in the new system?
  • What are the different options for migrating the data and what are the costs? (Are there cost benefits for doing something different?)
  • What is the timeline? When do you need the data and when will it be in the new system ready to review?

Data migration really comes down to getting the most useful data you can into the new system. If you are not going to use the data for reporting, it is all right to get the data in summary form (like a PDF of a progress note). If you need the data for reporting or quality metrics, it may be best to pay to have the data migrated. You really have to look at the cost benefit of having the data for reporting vs the cost of getting the data migrated.

I know this is a lot of information to gather, review, and understand, but the more you know, the less you will be surprised by the process. It also helps prevent issues during implementation when you expect one thing and are provided another.

Remember: When you are moving, it’s okay to get rid of stuff you don’t need. Oh… and don’t forget the garage door opener!

The above article on EMR data migration for your medical practice has been brought to you by the Mi7 team, who not only know how to move the junk in the trunk, they also know a thing or two (or a hundred) about moving your patient records, data, and vital stats out of your existing electronic health records system into a new one. Email them today to find out more. Oh, and they’ll help you decide whether to dispose of the gum wrappers you find under the seat.

If you can’t stand up, sit down! And cleaning up data migration messes.

For those who work and office (or live) with someone else, have you ever walked in the restroom and found that someone has left a mess on the floor? I’m not talking about the trash turned over, although that is ridiculous unless you have a pet that likes to turn over garbage. I’m talking unidentified fluids on the floor. Someone missed the giant hole that is the toilet. Now, granted, most of the time a male is the culprit. As males, every single one of us has had times where we point in one direction and it goes another. This is just a fact of life. The key is how you handle the mess.

This is another of those workplace metaphors. There are times that you make mistakes. There are times you create a mess. That’s going to happen. Maybe it’s not even “your fault.” In my 20 years in the IT industry, I have made my share of messes. The key character trait is how you respond to those messes: do you clean it up yourself or do you leave it for someone else?

Recently we received data from another EMR vendor from which one of our clients was moving. We had already migrated several different types of data, but when we got to the document migration, the data was a mess. Multipage documents were broken apart into single page documents and the document compression (these were TIFF’s) was not correct for the system to which we were migrating.

We typically require sample files before we quote a project, but the vendor providing the data made getting samples cost prohibitive for the client, so we went without a sample this time. This was a mess we needed to clean up without additional cost to the client. We ended up spending hundreds of hours of processing time to combine the single page documents into the appropriate multipage documents and re-compressing the documents into the proper format. It took much longer to process than the time we budgeted, but it was the right thing to do.

I know that no one person can have all of the skill sets to clean up all messes for all time. That is the reason we work with other people. We have a support network to help us with things that we don’t know how to do or can’t handle by ourselves.

The people I want to work with are people that recognize when they have made a mess. They clean up messes they can handle and call people when they need help. They don’t just leave the mess for someone else to find and clean up for them.

When you are working in the service industry (any industry really), you must be willing to admit to your mistakes and come up with a plan to correct them. The key to this process is, once again, COMMUNICATION. Communicate the issue and demonstrate that you understand the issue. Communicate that you own the issue, communicate the plan, communicate the status, communicate completion and communicate how you will prevent the issue from happening again. Customers will appreciate your admission of humanity and humility. They will appreciate your willingness to take charge of the situation and make things right. Above all, they will appreciate that they know what is happening because you have kept them informed with your proper communication.

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.

Mi7 Solutions Featured in the St. Louis Business Journal’s Tech Flash

St Louis Tech Startup, EMR Interfaces, IntegrationThe St. Louis Business Journal’s Brian Feldt recently interviewed Mi7 Solutions’ founder Brad Cassity about his recent departure from Curas and the launch of Mi7. The article discussed the increased need for lab device
integration, data extraction and migration, and system interfaces for Electronic Health Records systems being used in hospital and medical practice environments. Cassity stated in the article:

“We’ve seen a big need from clients at Curas who were looking at other softwares or mobile solutions and wanting to use another system … [practices are also] looking to move systems and finding other EMR systems that can’t do what they originally thought….Their needs are growing more sophisticated, so they are going to other applications.”

The article can be read in its entirety on the St. Louis Business Journal website.