EMR Data Integration/Conversion – Do the pieces fit and are they accurate?

Medical data of all shapes and forms add additional contours to the existing IT Healthcare landscape, but what does it mean in layman’s terms? 

To simplify, one analogy is fairly clear, “You can throw the paper at the printer and hope some of it makes it into the feed or you can put the stack in the tray.”  Like everything else in life, wondrous variety exists in types of data and integrated systems from differing vendors to data fields and similar data sets.  Like the printer, if the formats are “groomed,” it eases complexity and adds efficiency to migrations.

Why does it matter? 

Not all data structures are created equal or contains equal languages and values.  To better suit both integration and data standards, it often helps to develop a template to corral the data into a clear and useful format.  System “A” may contain a date of birth in “month/day/year” format while System “B” may define the same value under a different field and carry with it a Julian calendar format (3 numeric digits 001-365 for the day of the year and 2 or 4 digits for the year.)  Though it is a rare occurrence, this type of difference provides illustration of the challenges involved in making one system’s data useful by the new system’s operational conventions.  Health Information Exchanges had the right idea of making data fit specific criteria for interoperability, but many vendors and homegrown/custom EMR systems maintain and use formats that do not match.  Due to the mismatch, transformation and validation become the keys to successfully migrating data to new systems.

ETL (Extract/Transform/Load)
  • Extract
    • Identify needed data
    • Copy data out in a format that is clear and useful
  • Transform
    • Modify the format of the data to fit the new system (format of fields, dates, visits, etc...)
    • Maintaining the content as originally collected (nothing is added or removed from the user viewable content)
  • Load
    • Import the data to the new system in a format that can be read and matches the existing format
  • Master Patient Index (MPI)
    • Is data loaded? How? Is it incremental?
    • How does it compare to the new system’s MPI?
      • If the data does not match between systems and is not corrected, documentation and information may appear to be “missing"
    • Validation and testing plans
      • Are they defined?
      • Do they focus on all needs (legal and content)?
Why Validate?
  • Patient Safety
    • As an example of patient safety related validation, an order from a physician to maintain life-sustaining treatment (POLST) or an advanced directive such as “Do not resuscitate” (DNR) can have catastrophic results if the data is not placed in the appropriate location within a patient chart. Is it “Patient Level” where it applies to all visits the patient may have or is it “Visit/Encounter Level” and only applies to a singular visit or admit?  At this point the risk is clear, if a patient has a DNR that they want applied only in the instance of a highly risky procedure that could leave them impaired, a mismatch in location could cause the order to appear on every visit (possibly applying to a simple procedure such as a tonsillectomy or general anesthesia.)  Most caregivers cringe at the concept, but this is a “worst-case scenario.”  Medical staff and facilities also tailor policies and procedures around avoiding these “worst-case scenarios.”  Though it is a disturbing realization, steps are taken during data conversions to avoid these critical instances.
  • Legal Compliance
  • Efficiency
  • Data Retention
    • How long do we need to keep data? What is the current federal standard?  What is our best practice?  Validation allows for accurate historical data.  Though a record may be old, accuracy is also required for any instance where an emergency or legal issue may require its retrieval.
How do we validate?
  • Sampling
    • Sampling of converted data allows us to see cross-sections of patient types, document types, and varying data sets to make certain that we have use of as much data as possible for an accurate conversion.
  • Testing, testing, testing
    • Testing is also a fully encompassing process that gives us scenarios in a closed environment to confirm that all pieces of an application work properly and that the data functions as intended (is available where and when it is needed). If the function or data does not work or appear as required, work to remediate the issue begins.
  • Crosswalks
    • Crosswalks are designed to validate that the applicable data is applied to the appropriate patient and not just someone with the same name. These crosswalks match details available in databases such as SSN, Date of Birth, Address, Age, Sex, etc.  An example of a crosswalk table to isolate and correct mismatches would be that system “A” has “12345” as a visit number, system “B” has “678901” as the visit number.  A table that contains the logic that system “A’s” number references system “B’s” number looking for mismatches resolves the issue.  When looking up the old number, the new number will be displayed.
  • Multiple level data audit
    • Finally, the Multi-level audits allow us to pinpoint issues and make certain that there are no errors and the information is 100% valid.

While variances exist in methods, the goals are all similar.  How do we get from point “A” to point “B” with the most accurate and cost-effective methods?  Planning is vital and extracting data that is incorrect in the source system will equate to faulty data in the new system.  An eye for details is a requirement for the duration of extraction and conversion processes and teamwork in all areas around the conversion amplify successes.

What are your thoughts? Feel free to comment below!



Greg J. Heffner, Director of Legacy Support and Data Services
615.684.5556  |  gheffner@hctec.com


Want to receive notifications of new blog posts? Just subscribe to the HCTec Blog HERE.