[{"innerBlocks":[],"name":"core\/freeform","postId":125870,"blockType":{"name":"core\/freeform","keywords":[],"attributes":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"providesContext":[],"usesContext":[],"selectors":[],"supports":{"className":false,"customClassName":false,"reusable":false},"styles":[],"variations":[],"apiVersion":3,"title":"Classic","description":"Use the classic WordPress editor.","category":"text"},"originalContent":"\u201cIt\u2019s time to replace our EMR.\u201d 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\u2019t enough translators to explain each country\u2019s positions.In healthcare, every institution tries to bridge the gap between patient care and administration while using different \u201clanguages\u201d 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\u2019s 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\u2019ve 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\u2019re faced with new expectations, new rules and new standards which your EMR can\u2019t 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<\/b>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.<\/li>
Minimizes data re-entry costs.<\/li>
Maintains discrete data analytics and clinical decision support capabilities.<\/li><\/ul>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\u2019s 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\u2019s caregivers to easily find information about a patient\u2019s 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<\/b>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\u2019s not a matter of export\/import. Instead, it\u2019s a true ETL process\u2014extract, 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\u2019s 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\u2019t 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\u2014pharmacy\u2019s for mapping medications, clinicians\u2019 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 \u201cseafood allergy.\u201d Without specifics about the nature of the seafood allergy, the new EMR will be unable \u201cto trigger important patient safety system alerts\u201d such as those pertaining to drug-allergy interactions. If translating and coding are inaccurate, the new EMR \u201cwill not be able to properly transfer this important part of a patient\u2019s record to another healthcare system,\u201d 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 \u201cwell.\u201d This information is categorized and migrated to the new EMR but it will be uncertain that this child is well enough to be considered \u201ccured,\u201d 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<\/b>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\u2019 shoulders to do manually.","saveContent":"\u201cIt\u2019s time to replace our EMR.\u201d 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\u2019t enough translators to explain each country\u2019s positions.In healthcare, every institution tries to bridge the gap between patient care and administration while using different \u201clanguages\u201d 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\u2019s 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\u2019ve 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\u2019re faced with new expectations, new rules and new standards which your EMR can\u2019t 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<\/b>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.<\/li>
Minimizes data re-entry costs.<\/li>
Maintains discrete data analytics and clinical decision support capabilities.<\/li><\/ul>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\u2019s 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\u2019s caregivers to easily find information about a patient\u2019s 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<\/b>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\u2019s not a matter of export\/import. Instead, it\u2019s a true ETL process\u2014extract, 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\u2019s 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\u2019t 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\u2014pharmacy\u2019s for mapping medications, clinicians\u2019 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 \u201cseafood allergy.\u201d Without specifics about the nature of the seafood allergy, the new EMR will be unable \u201cto trigger important patient safety system alerts\u201d such as those pertaining to drug-allergy interactions. If translating and coding are inaccurate, the new EMR \u201cwill not be able to properly transfer this important part of a patient\u2019s record to another healthcare system,\u201d 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 \u201cwell.\u201d This information is categorized and migrated to the new EMR but it will be uncertain that this child is well enough to be considered \u201ccured,\u201d 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<\/b>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\u2019 shoulders to do manually.","order":0,"get_parent":{},"attributes":[],"attributesType":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"dynamicContent":""}]

The role of clinical data mapping in EMR data migration

More for you