A Guide To Data Evaluation And Multiple Formats

This is the second part of a blog series that guides healthcare organizations that are thinking about embarking on their data archival journey.

Data governance is a huge topic and it’s important to understand that a good archiving process is not focused on saving everything. For instance, you may find a difference of opinion between IT and HIM when it comes to deciding what is necessary to archive. Assembling your project team to discuss and determine what is both necessary for compliance vs necessary for ongoing patient care is step one. Providing an outline for what needs to be archived will benefit both your project team and the vendors involved.

How to determine which data to archive?

Before getting started with any archiving project it is essential to create and follow your Retention and Compliance requirements – this will provide a starting point and the general criteria for building your historical patient charts. Taking into account key elements like DOS, DOB-Peds, and SRVS/TYPE will provide the criteria for what can be excluded from the extraction process …for example in the case of charts older than 7 years from DOS or Discharge, you may be able to exclude this data and lessen the total amount of data and effort in the extraction. Of course, using other standard criteria like DOB in the case of pediatric files, you can include data associated with pediatric records that require 18-year retention and then utilize fields like service and type to determine which specific reports and results also need to be excluded from the extraction process.

Here are some key factors that healthcare organizations must think through during the data evaluation phase.

• Database and Storage Formats: Number of systems, modules, and databases will impact the total effort and help to define output options and storage formats. Understanding output formats, and data conversion is necessary for determining the level of services required. For example, modules like PACs will require DICOM file format support which is why defining these details during the initial evaluation stage is important.
• Is your data hosted or onsite? Key questions that require serious consideration are:
  • Is your data on-prem or hosted?
  • Do you have vendor support?
  • Determining the level of effort per team?

  A fully hosted solution that is maintained by the Vendor may not allow for database access and require the vendor to provide the extracted data. But on the opposite end, you could have a database onsite that has minimal vendor support and would require a larger effort from either your internal application support team and/or your archive vendor team to extract the data.

• Export Options (Per Module): The next important step is to determine export options and any potential system limitations. Having multiple export options will allow you to determine what will work best for migrating and archiving your data. You may be limited by the export options available from your legacy system and even the method of extraction. For example, systems that only allow for single chart export options can be cumbersome vs systems that allow for scripting bulk exports in a variety of formats. Understanding these options is critical to determining the level of effort needed per team. A sure-fire way is to export multiple samples that are tied to a review-and-approval process.
• Legacy Vendor Support (Tools/Cost): While defining the export option, we must understand the level of effort required from each team. Three basic types could be drawn from this: 1) full extraction from the legacy system service provider 2) joint effort from both the legacy system service provider and the internal application team, and 3) lastly, the unsupported system that will require full support from the archival service provider.
• Discrete Vs Non-Discrete: During the data evaluation stage, it must be determined what is necessary to be exported as discrete data vs non-discrete data. For example, If report or result data is stored in tables, it can be mapped to the new system or sent to the archive in a discrete format. File-based data, such as scanned documents, images, or PDF files are considered non-discrete data that will need to be stored and archived in their original format.
• Data Mapping: This is where discrete data from your legacy system can be exported and mapped to similar tables in your new EMR or archival system. The next step is determining what specifically should get mapped to the new EMR and what needs to be sent to the archive. Options range from mapping all discrete data to the new EMR to a small subset of only the most recent data, either way, the archive must be integrated into the new EMR at the point of going live for ease of access to the historical patient charts.
• Reports and Documentation: This is non-discrete data that can be in many different formats and styles. Quite often legacy systems will be limited to these types of export options. Typically, these are industry standard formats that are already in a readable format, making it easier for clinical staff to review. These formats can be easily uploaded to the new EMR as well as to the archival system.
• Active or Static Archiving: Lastly, one would need to determine whether there is an ongoing need to archive the data. The data exported from the Legacy system will always be set to the read-only mode but if there is a need for adding notes or additional support-related information, then an archive can be set to active. For example, we have seen ROI export requests added to the archive upon the completed ROI export for the client or provider. Some clients may even decide to utilize their archival system for scanning or annually to export system data and free up critical system storage.