An enterprise roadmap to data conversions

Scott-IsaacsonA data strategy is an essential part to your organization’s growth, whether through mergers, acquisitions, affiliations, or joint partnerships. You’ve worked hard to create and manage your data, so focus on retention (holding on to information to meet regulatory requirements) and convenience (making your existing data available in a meaningful way). Data conversions are frequently required, starting with deciding what data you want to convert, extracting it from the source system, [sometimes] transforming it in a meaningful way, loading it into the new system, and validating that the data converted properly. To set realistic expectations, realize value, and keep patients safe, it is critical to define an enterprise roadmap for your data conversions.

Imagine this nightmare: a provider begins chart review before seeing their patient and notices that some (but not all) of their lab results are listed twice. They also notice that the patient’s entire past medical history is now considered part of the active problem list. Not the sweet dreams the provider was hoping for – let’s start sketching a roadmap.

Start small

Begin by establishing a working group empowered to make meaningful decisions, a process for making those decisions, goals, and guiding principles that can be referenced when making decisions about data conversions. Visit those goals and guiding principles before each meeting with your working group and use them to frame each decision that needs to be made.

Continue by breaking down the project into some very high-level requirements, determining which systems, patients, and timeframes should be converted. You’ll continue to iterate on those requirements, but you have to start somewhere.

It is also helpful to break down data conversions into two buckets – patient-level and visit/encounter-level. Patient-level data such as the demographics, legacy MRNs, problem lists, and active medications are commonly converted. Visit/encounter-level data, including notes, visit diagnoses, and vitals, usually make the cut, too. These definitions help group data elements together and determine how much value you might realize if you convert them. Many decisions will be made on an element-by-element basis.

Put [very sensible] stakes in the ground

One of the most important things you can do is establish realistic, consistent, and well-communicated boundaries around your data conversions. Allowing each specialty or user group to choose their own time length will provide a medical record that’s impossible to navigate. You never want your end users wondering if data was missed, never existed, or simply wasn’t converted. Instead, strive for realistic (say, one year), consistent (across all specialties), and well-communicated conversions (in training material, discussed during department meetings, emailed and on your intranet, and in the back pocket of every support resource, etc.).

System configurations are not all the same; a new EHR implementation or consolidation allows for an opportunity for a reset. Many organizations admit that some data elements (legacy problem list or medication list, for example) are inaccurate or out of date. Some of those fundamental differences between systems could mean that converting some data just doesn’t make sense. If data stored in the legacy system is free text, attempting to convert it to discrete data will be impossible.

Invite your HIM and compliance friends to the party (they won’t want to miss it)

State and federal guidelines dictate how long you must retain records and how rich those records need to be. Your friends in HIM and compliance know those requirements well and should be involved in your initial conversations. As you consider your conversion strategy, remember that it is not easy to meet the requirements for your organization’s legal medical record as you convert data from one system to another. Conversions may miss some of that richness, including audit trails, previous versions, or who did what.

As a bonus, they also have some great context and historical knowledge that will be crucial for your most fundamental conversion – master patient index (MPI). Understanding patient crossover between two systems will allow you to make informed decisions on whether a data element is worth converting. Their understanding of historical decisions for legacy medical record numbers (MRN) is also a great party trick.

Consider alternatives to converting historical data

If your conversions won’t meet your legal medical record requirements, you still need a plan to retain that historical data. Here are a few options to consider:

Option A – Retain the old system in a limited fashion. This can involve a read-only or hosted version of your existing system (hopefully at a lesser cost than you’re paying for full upkeep). This also provides a clean break to understand the source system for data: legacy system prior to go-live, new system after. Some vendors may put up roadblocks to providing data in a timely fashion, so leaving it in the source may be a smoother ride.

Option B – Work with an archival system and vendor. A partnership with a trusted third party can solve a lot of your retention woes:

  • Allows for multiple legacy systems to be archived into a single platform; archival systems are experienced in ingesting data from multiple source systems and have expertise in a wide variety of EHRs and third parties.
  • Some archival systems allow for data to be modified over the course of business, such as working down archived accounts receivable in the archive (instead of the legacy system).
  • Most archival systems can be linked directly from your EHR; a single button can be used to pass on credentials and patient context to prevent you having to log in and look the patient up again.

Option C - Identify other sources of data. If you’ve previously interfaced lab result data to a regional or state-wide health information exchange, is it necessary to convert that same data from the legacy to new EHR? Is there an automated process that will make that data available? Can your e-prescribing vendor provide medication history information?

Finally, consider manual abstraction. In some cases, it’s advantageous to have end users live in the system converting specific data by hand – scheduled appointments and medication lists are great examples. It provides them with a chance to practice and be comfortable with the system prior to go-live.

Get comfortable with the hard truths

Before you sign your masterpiece of a roadmap, remember:

  • Data conversions are complicated, take a lot of time and resources, and an intense amount of validation – including valuable clinician time.
  • You probably won’t use as much of your converted data as you might think. Be open and honest about what you need.
  • Legal medical record requirements are difficult to meet through data conversions. Other options are available.
  • Some of your users will be working out of two systems for a period, and that’s okay. It’s most important that everyone knows what lives where.

The road to smooth data conversations can be a bit bumpy. If your organization needs help with its roadmap, let’s talk.



Topics: Implementation, featured

Subscribe to receive blog updates