Archive for Data Extraction

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.

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?
Process
  • 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?
Cost
  • What are the different options for migrating the data and what are the costs? (Are there cost benefits for doing something different?)
Timeline
  • 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.

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.