The role of clinical data mapping in EMR data migration
There are an array of challenges that healthcare organizations face once they decide to proceed with the migration of legacy data to a new EMR.
“It’s time to replace our EMR.”
That one simple statement is often prelude to anxious contemplation, discussion, fear, uncertainty and doubt. After a healthcare organization (HCO) decides to proceed with the migration of its legacy data to a new EMR, an array of challenges must be met. At their root is the fact that healthcare information systems resemble a dysfunctional meeting of the United Nations; there may be agreement on objectives, but there aren’t enough translators to explain each country’s positions.
In healthcare, every institution tries to bridge the gap between patient care and administration while using different “languages” with different data formats, data models and vocabularies. This gap in understanding wastes an estimated $30 billion every year, as HCOs struggle to represent accurately a source system’s clinical data in an equivalent location in the new target system.
Much of the anxiety associated with transitions between EMRs can be explained by the natural reaction to change. It is discomforting to realize that the system you’ve grown accustomed to and administered for years has reached the natural end of its usefulness. Concepts such as meaningful use, population health and value-based care were unknown when your EMR first went live, and now, suddenly, you’re faced with new expectations, new rules and new standards which your EMR can’t meet.
Nevertheless, healthcare organizations have accepted the inevitable. Half of all HCOs will be running their second EMR by the end of next year. And it is increasingly well understood that value can be attained by making the transition.
The value of data migration as part of EMR and EHR transition
By now, there is no question that data migration from the source system to the target system is an essential component of the EMR-replacement process. It is generally understood that data migration:
However, data migrations are contingent upon the accurate mapping of the clinical data elements in the source system so that no important information is omitted from the new target system. And that is something that can easily happen.
It’s important to recall why medical information became so prone to misunderstandings. There were hardly any standards governing medical content. The earliest EMRs devised proprietary terminology to make it possible for a health system’s caregivers to easily find information about a patient’s medications or allergies.
But the emergence of a Unified Medical Language System forced EMRs to migrate or translate the meaning of their terms into the understandable terminology of the new standards.
Initiatives such as the Yosemite Project have long been underway to achieve sematic interoperability of all structured healthcare information based on Resource Description Framework (RDF) as a universal information representation. But the fact remains that many EHR and EMR systems maintain proprietary and exclusive dictionary and codification standards, some of which are customizable at the organization level as well. As a result, achieving semantic equivalence of ontologies from system to system is often a significant undertaking.
The mapping ordeal
Data mappings and translations are a major component of executing a clinical data migration and will ultimately drive the end-user experience and potential configuration requirements of the target system. The process of EMR data migration almost always results in some fundamental alteration 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/import. Instead, it’s a true ETL process—extract, transform, load. The shape of the data is changed. Sometimes data types undergo conversions, such as a number to a string, which, if done poorly, can result in loss of precision. Data sets, such as order codes, result codes, diagnosis categories, note types and various other types of dictionaries 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 altogether. It’s frequently not possible to know for sure what the data actually looked like in the legacy system once this process is complete and the legacy system has been sunset.
Mapping is hard work. It is time-consuming and resource-consuming. But incomplete migrations or incorrect mapping has serious implications. Examples abound. Suppose the ambulatory portion of an organization is migrating its data (with its own nomenclature) to the already established EMR being used by the in-patient sector of the organization, whose terminology doesn’t match that of the ambulatory units.
Another barrier to accurate mapping must be faced when trying to access information about patient medications. Doses change, units may be altered; equivalence in the way this information is presented in both the source EMR and the target system is rare. Correct mapping of such data requires different resources—pharmacy’s for mapping medications, clinicians’ for mapping allergies, and each is often displayed differently from system to system.
In a commentary for Electronic Health Reporter, Calvin Chock describes a mapping problem that can emerge when a patient is listed as having a “seafood allergy.” Without specifics about the nature of the seafood allergy, the new EMR will be unable “to trigger important patient safety system alerts” such as those pertaining to drug-allergy interactions. If translating and coding are inaccurate, the new EMR “will not be able to properly transfer this important part of a patient’s record to another healthcare system,” or patient portal or clinical decision support service or Health Information Exchange.
Proper mapping also has implications for workflow. Mappers must understand the protocols governing the workflows of the target system and that mapping cannot be based on clinical equivalence alone. For example, we may find a note that shows a child referred to in the source system as “well.” This information is categorized and migrated to the new EMR but it will be uncertain that this child is well enough to be considered “cured,” or if instead the note means the child is making progress towards recovery.
Instances such as this demonstrate the need for additional help in the mapping process, for example, from physicians. These providers must be part of the governance that determines how to correctly migrate data elements to be mapped. They are essential players in the reconciliation process that must translate information from the source EMR to the target EMR.
Mapping suggestions reduce manual effort and deliver value
Because native EHR vendors often fall short with regards to semantic management, semi or full automation of dictionary, nomenclature and ontology mapping are critical to the reduction of manual effort and invaluable to the delivery of continuity of care. Probabilistic or machine learning solutions can address the majority of mapping requirements, leaving a subset of exceptions to be addressed manually. Regardless of approach, one thing is certain: the more effort spent on the mapping, the greater the value to be achieved, with less mapping landing on the providers’ shoulders to do manually.
That one simple statement is often prelude to anxious contemplation, discussion, fear, uncertainty and doubt. After a healthcare organization (HCO) decides to proceed with the migration of its legacy data to a new EMR, an array of challenges must be met. At their root is the fact that healthcare information systems resemble a dysfunctional meeting of the United Nations; there may be agreement on objectives, but there aren’t enough translators to explain each country’s positions.
In healthcare, every institution tries to bridge the gap between patient care and administration while using different “languages” with different data formats, data models and vocabularies. This gap in understanding wastes an estimated $30 billion every year, as HCOs struggle to represent accurately a source system’s clinical data in an equivalent location in the new target system.
Much of the anxiety associated with transitions between EMRs can be explained by the natural reaction to change. It is discomforting to realize that the system you’ve grown accustomed to and administered for years has reached the natural end of its usefulness. Concepts such as meaningful use, population health and value-based care were unknown when your EMR first went live, and now, suddenly, you’re faced with new expectations, new rules and new standards which your EMR can’t meet.
Nevertheless, healthcare organizations have accepted the inevitable. Half of all HCOs will be running their second EMR by the end of next year. And it is increasingly well understood that value can be attained by making the transition.
The value of data migration as part of EMR and EHR transition
By now, there is no question that data migration from the source system to the target system is an essential component of the EMR-replacement process. It is generally understood that data migration:
- Minimizes provider disruption by facilitating continuity in workflow and automation.
- Minimizes data re-entry costs.
- Maintains discrete data analytics and clinical decision support capabilities.
However, data migrations are contingent upon the accurate mapping of the clinical data elements in the source system so that no important information is omitted from the new target system. And that is something that can easily happen.
It’s important to recall why medical information became so prone to misunderstandings. There were hardly any standards governing medical content. The earliest EMRs devised proprietary terminology to make it possible for a health system’s caregivers to easily find information about a patient’s medications or allergies.
But the emergence of a Unified Medical Language System forced EMRs to migrate or translate the meaning of their terms into the understandable terminology of the new standards.
Initiatives such as the Yosemite Project have long been underway to achieve sematic interoperability of all structured healthcare information based on Resource Description Framework (RDF) as a universal information representation. But the fact remains that many EHR and EMR systems maintain proprietary and exclusive dictionary and codification standards, some of which are customizable at the organization level as well. As a result, achieving semantic equivalence of ontologies from system to system is often a significant undertaking.
The mapping ordeal
Data mappings and translations are a major component of executing a clinical data migration and will ultimately drive the end-user experience and potential configuration requirements of the target system. The process of EMR data migration almost always results in some fundamental alteration 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/import. Instead, it’s a true ETL process—extract, transform, load. The shape of the data is changed. Sometimes data types undergo conversions, such as a number to a string, which, if done poorly, can result in loss of precision. Data sets, such as order codes, result codes, diagnosis categories, note types and various other types of dictionaries 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 altogether. It’s frequently not possible to know for sure what the data actually looked like in the legacy system once this process is complete and the legacy system has been sunset.
Mapping is hard work. It is time-consuming and resource-consuming. But incomplete migrations or incorrect mapping has serious implications. Examples abound. Suppose the ambulatory portion of an organization is migrating its data (with its own nomenclature) to the already established EMR being used by the in-patient sector of the organization, whose terminology doesn’t match that of the ambulatory units.
Another barrier to accurate mapping must be faced when trying to access information about patient medications. Doses change, units may be altered; equivalence in the way this information is presented in both the source EMR and the target system is rare. Correct mapping of such data requires different resources—pharmacy’s for mapping medications, clinicians’ for mapping allergies, and each is often displayed differently from system to system.
In a commentary for Electronic Health Reporter, Calvin Chock describes a mapping problem that can emerge when a patient is listed as having a “seafood allergy.” Without specifics about the nature of the seafood allergy, the new EMR will be unable “to trigger important patient safety system alerts” such as those pertaining to drug-allergy interactions. If translating and coding are inaccurate, the new EMR “will not be able to properly transfer this important part of a patient’s record to another healthcare system,” or patient portal or clinical decision support service or Health Information Exchange.
Proper mapping also has implications for workflow. Mappers must understand the protocols governing the workflows of the target system and that mapping cannot be based on clinical equivalence alone. For example, we may find a note that shows a child referred to in the source system as “well.” This information is categorized and migrated to the new EMR but it will be uncertain that this child is well enough to be considered “cured,” or if instead the note means the child is making progress towards recovery.
Instances such as this demonstrate the need for additional help in the mapping process, for example, from physicians. These providers must be part of the governance that determines how to correctly migrate data elements to be mapped. They are essential players in the reconciliation process that must translate information from the source EMR to the target EMR.
Mapping suggestions reduce manual effort and deliver value
Because native EHR vendors often fall short with regards to semantic management, semi or full automation of dictionary, nomenclature and ontology mapping are critical to the reduction of manual effort and invaluable to the delivery of continuity of care. Probabilistic or machine learning solutions can address the majority of mapping requirements, leaving a subset of exceptions to be addressed manually. Regardless of approach, one thing is certain: the more effort spent on the mapping, the greater the value to be achieved, with less mapping landing on the providers’ shoulders to do manually.
More for you
Loading data for hdm_tax_topic #better-outcomes...