How to ensure your clinical data isn’t trapped during migration
Organizations such as Wellspan cope with e-discovery challenges at the same time that they’re going through the EHR replacement process.
One can only sympathize with healthcare CIOs who must struggle with interoperability issues, financial restraints and the threat to hospital networks and patient records posed by hackers.
Unfortunately, there is another challenge with which they will be forced to cope: e-Discovery requirements pertinent to audits, common law, statutes and regulations. As CIOs seek to retire and replace legacy clinical systems, these requirements become even more pronounced.
But in too many cases, they are not prepared. For example, they may not be able to identify and prioritize all the required data sets that need to exist and/or complement each other. They may not understand the common requirements set forth at the federal and state level.
And even if they and their legal counsel were completely up-to-date in their understanding of all these legal variables, they would still face the challenge of clinical documentation: how long must patient records be retained and where should all this historical data reside so that it can it be easily accessed.
It is tempting to hope that these legal pitfalls can be avoided by simply retiring legacy systems and shuttling users to a shiny new EMR. Flip the power switch and you’re done. But those legacy systems have countless millions of dollars’ worth of critical information, both from a continuity of care point of view and from a legal perspective. There are rules, some specific, some vague, about retaining this data.
Indeed, the task at hand can be so confusing at times that many organizations punt on the entire issue and just keep those legacy systems on minimal life support. But minimal life support does not always equate to minimal cost and risk. Savvy CIOs will retire these clinical systems, and the inherent risk that accompanies them, but are faced with the decision to pursue migration or archival of the data.
The process of EMR data migration almost always results in some fairly fundamental alterations of the legacy EMR data. The underlying data models used by EMRs differ greatly from one another, and it’s not a matter of export and import. Instead, it’s a true ETL process—extract, transform, load.
Why? Because the shape of the data is changed. Sometimes data types undergo conversions which, if done poorly, can result in loss of precision. Data sets such as order codes, result codes, diagnosis categories, and note types are mapped from the values in the legacy EMR to the values used by the new EMR. Fields that have no apparent corollary in the new EMR are often just ignored. Sometimes it’s impossible to know what data looked like in the legacy system once the legacy system has been retired.
From a clinical perspective, it’s probably not useful to take 15 years of legacy data and load that directly into your new EMR. Most organizations opt for something more likely to be relevant, while still preserving patient safety, perhaps three to five years of data. Although the state and federal requirements for archival are clear on how long you need to preserve data (from six years to forever, depending on a variety of factors), they aren’t nice enough to say that the data you need to preserve is limited to what is currently clinically pertinent. In other words, that 10-year-old test result is still, technically, part of the legal medical record.
R. Hal Baker, MD, senior vice president of clinical improvement and CIO at WellSpan, exemplifies the dilemma he faces on which clinical data should be migrated. “We are converting seven years of clinical data in our migration—we’re bringing over seven years of laboratory and clinical information for our patients. We recognize that that’s more than normal, but we think there’s value in having that depth in the record for our community.
“We have an archival strategy put in place to retire our legacy applications,” he adds. “With the absence of a rigorous purging strategy, the entire database record needs to be maintained for the longest patient for whom you have a record retention requirement. In our state, that would be the last baby born on the old record plus 21 years plus seven, so 28 years. Our statute of limitations is age of majority plus seven.”
Meanwhile, we must keep in mind that as the sophistication of clinical documentation has increased, so too have the lawyers’ requests for information when litigating cases and issuing eDiscovery requests. As said by Tim Schoerner, VP/CIO, UPMC Susquehanna, “That’s why we do a lot of the things we do. We’re protecting ourselves from lawsuits and litigation.”
Clearly, a migration isn’t going to cover all of the legal scenarios, and if the archive has everything we need legally and clinically, why not just skip that time-consuming and expensive migration process and only archive? Primarily, it’s because an archive-only approach means abandoning millions of dollars’ worth of hard-won documentation and all the automation and analytics that goes with that once the transition to the new EMR is complete.
An EMR is a lot more than a place to store clinical documentation. Virtually all modern EMRs have substantial functionality surrounding clinical decision support, health maintenance planning, and quality reporting. They also often are crucial sources of data for analytics suites that are the pillars of population health management. In short, not maintaining the easy availability of this data inside the active EMR is akin to having used paper charts up until your latest and greatest EMR was available. That’s not a reality that most organizations are comfortable with. One could certainly argue that much of the data in some EMRs, especially those that were implemented very early on in the transition to electronic records, contain a significant amount of “junk” data that ends up hurting more than it helps when migrated to a new system. Although that can be true, it also varies greatly on a patient by patient basis, and making a decision to abandon all data due to some bad data is rarely sound.
In broader terms, Baker offers a revealing insight into the various scenarios CIOs think about. “In my mind there are three buckets. There’s the data you need to import into the database. There is data that you don’t want to import in bulk but that you may want to import selectively later on. Then there’s the data you need right away. For example, I need to go back and look at the past reports from 15 years ago but I don’t necessarily need to move every pathology report from 15 years ago into the record. But I do need to have access to it from the archive system. Then there’s the metadata you need in the future for population health or business purposes. This may be information you didn’t realize you need but it becomes relevant if you face a legal medical audit or for quality or for billing purposes under statute of limitations for regulations.”
Ultimately, the decision to only archive should be based on hard numbers, not guesswork. Quantify the costs involved (patient safety issues, empty health maintenance plans, lack of population health management, the chance for data entry errors when re-entering data, inevitable penalties related to duplicate or missing testing, etc.) and weigh that against the cost of a data migration. In many cases, data migrations are far less costly than any attempt at manual population of data when all these factors are considered.
Every healthcare CIO needs a solid strategy for how they’re going to deal with legacy EMR applications as they replace and transition. CIOs must not treat this topic lightly; otherwise they can be at considerable risk if their legacy systems are breached and their organization is stuck in the news for all the wrong reasons.
Unfortunately, there is another challenge with which they will be forced to cope: e-Discovery requirements pertinent to audits, common law, statutes and regulations. As CIOs seek to retire and replace legacy clinical systems, these requirements become even more pronounced.
But in too many cases, they are not prepared. For example, they may not be able to identify and prioritize all the required data sets that need to exist and/or complement each other. They may not understand the common requirements set forth at the federal and state level.
And even if they and their legal counsel were completely up-to-date in their understanding of all these legal variables, they would still face the challenge of clinical documentation: how long must patient records be retained and where should all this historical data reside so that it can it be easily accessed.
It is tempting to hope that these legal pitfalls can be avoided by simply retiring legacy systems and shuttling users to a shiny new EMR. Flip the power switch and you’re done. But those legacy systems have countless millions of dollars’ worth of critical information, both from a continuity of care point of view and from a legal perspective. There are rules, some specific, some vague, about retaining this data.Indeed, the task at hand can be so confusing at times that many organizations punt on the entire issue and just keep those legacy systems on minimal life support. But minimal life support does not always equate to minimal cost and risk. Savvy CIOs will retire these clinical systems, and the inherent risk that accompanies them, but are faced with the decision to pursue migration or archival of the data.
The process of EMR data migration almost always results in some fairly fundamental alterations of the legacy EMR data. The underlying data models used by EMRs differ greatly from one another, and it’s not a matter of export and import. Instead, it’s a true ETL process—extract, transform, load.
Why? Because the shape of the data is changed. Sometimes data types undergo conversions which, if done poorly, can result in loss of precision. Data sets such as order codes, result codes, diagnosis categories, and note types are mapped from the values in the legacy EMR to the values used by the new EMR. Fields that have no apparent corollary in the new EMR are often just ignored. Sometimes it’s impossible to know what data looked like in the legacy system once the legacy system has been retired.
From a clinical perspective, it’s probably not useful to take 15 years of legacy data and load that directly into your new EMR. Most organizations opt for something more likely to be relevant, while still preserving patient safety, perhaps three to five years of data. Although the state and federal requirements for archival are clear on how long you need to preserve data (from six years to forever, depending on a variety of factors), they aren’t nice enough to say that the data you need to preserve is limited to what is currently clinically pertinent. In other words, that 10-year-old test result is still, technically, part of the legal medical record.
R. Hal Baker, MD, senior vice president of clinical improvement and CIO at WellSpan, exemplifies the dilemma he faces on which clinical data should be migrated. “We are converting seven years of clinical data in our migration—we’re bringing over seven years of laboratory and clinical information for our patients. We recognize that that’s more than normal, but we think there’s value in having that depth in the record for our community.
“We have an archival strategy put in place to retire our legacy applications,” he adds. “With the absence of a rigorous purging strategy, the entire database record needs to be maintained for the longest patient for whom you have a record retention requirement. In our state, that would be the last baby born on the old record plus 21 years plus seven, so 28 years. Our statute of limitations is age of majority plus seven.”
Meanwhile, we must keep in mind that as the sophistication of clinical documentation has increased, so too have the lawyers’ requests for information when litigating cases and issuing eDiscovery requests. As said by Tim Schoerner, VP/CIO, UPMC Susquehanna, “That’s why we do a lot of the things we do. We’re protecting ourselves from lawsuits and litigation.”
Clearly, a migration isn’t going to cover all of the legal scenarios, and if the archive has everything we need legally and clinically, why not just skip that time-consuming and expensive migration process and only archive? Primarily, it’s because an archive-only approach means abandoning millions of dollars’ worth of hard-won documentation and all the automation and analytics that goes with that once the transition to the new EMR is complete.
An EMR is a lot more than a place to store clinical documentation. Virtually all modern EMRs have substantial functionality surrounding clinical decision support, health maintenance planning, and quality reporting. They also often are crucial sources of data for analytics suites that are the pillars of population health management. In short, not maintaining the easy availability of this data inside the active EMR is akin to having used paper charts up until your latest and greatest EMR was available. That’s not a reality that most organizations are comfortable with. One could certainly argue that much of the data in some EMRs, especially those that were implemented very early on in the transition to electronic records, contain a significant amount of “junk” data that ends up hurting more than it helps when migrated to a new system. Although that can be true, it also varies greatly on a patient by patient basis, and making a decision to abandon all data due to some bad data is rarely sound.
In broader terms, Baker offers a revealing insight into the various scenarios CIOs think about. “In my mind there are three buckets. There’s the data you need to import into the database. There is data that you don’t want to import in bulk but that you may want to import selectively later on. Then there’s the data you need right away. For example, I need to go back and look at the past reports from 15 years ago but I don’t necessarily need to move every pathology report from 15 years ago into the record. But I do need to have access to it from the archive system. Then there’s the metadata you need in the future for population health or business purposes. This may be information you didn’t realize you need but it becomes relevant if you face a legal medical audit or for quality or for billing purposes under statute of limitations for regulations.”
Ultimately, the decision to only archive should be based on hard numbers, not guesswork. Quantify the costs involved (patient safety issues, empty health maintenance plans, lack of population health management, the chance for data entry errors when re-entering data, inevitable penalties related to duplicate or missing testing, etc.) and weigh that against the cost of a data migration. In many cases, data migrations are far less costly than any attempt at manual population of data when all these factors are considered.
Every healthcare CIO needs a solid strategy for how they’re going to deal with legacy EMR applications as they replace and transition. CIOs must not treat this topic lightly; otherwise they can be at considerable risk if their legacy systems are breached and their organization is stuck in the news for all the wrong reasons.
More for you
Loading data for hdm_tax_topic #better-outcomes...