Posted by: RedaChouffani
Conversion, EHR, PM
In recent years, a number of health organizations have engaged in implementing a new EHR patient scheduling system, or a patient billing and registration system. However, many faced the daunting task of identifying how staff would be able to operate in a new system when much of the data will most likely continue to live for many months in the legacy application. Many organizations acquire conversion services from the software vendors or third party vendors in order to reduce added data entry during the transition to a new system.
For the most part a system conversion is defined as: Having data (clinical, billing, scheduling, and other data) extracted from the legacy system and then adjusted and loaded into the new system in order to reduce manual data entry and provide continuity of the records.
There are eight main considerations to reduce duplicating the staff’s work, maintaining clean data, and reducing the challenges associated with working in two systems.
Data set definition: As with any conversion, it is critical to define the scope of which data sets will be converted and brought over from the legacy system. This requires collaboration amongst the new vendor, data analysts, database administrators, and, in some cases, the legacy system support team. All stakeholders will agree and define what data sets would be available for extraction during this stage, and then the new system team will then confirm if all or parts of the extracted data will be transferable into the new system. It is ideal if the legacy system supports continuity of care document (CCD)/continuity of care record(CCR) data exports for a clinical data conversion. This allows for all clinical data to be extracted and stored in a standard format that most certified EHR packages can process. However, there still many known case where this functionality is not available, and the conversion team has to either go through the data dictionary and select a subset of information to be converted, or simply maintain the legacy system and keep it online. For non-clinical data such as billing and schedules, it is common practice to simply bring over patient demographics alone with account notes and balances. This is mostly due to the variations of how different systems handle patient billing internally.
Data format: In data conversions the data can be made available as a PDF, XML, raw text, HL7 and many other available formats. These are formats that are based on the source system and would sometimes need to be modified and exported into other formats to match the format needed by the new destination. The information can be maintained in a database and is then directly pushed into the new system, in other cases.
Workflow post conversion: Post-conversion workflow is one of the areas that requires significant consideration. There are different approaches being used post conversion some of which are:
Same staff with two systems: This is one of one of the least favorable models but can be successful if the organization is willing to do whatever it takes to ensure success maintaining two systems with the same number of staff (after going live). This typically requires additional hours from the team working on the systems.
Outsource legacy system: There are companies available that would take over billing for an organization while the staff is on the new system during a billing or clinical data conversion. This is viable for a clinical conversion where the information is available on demand and can be added to the returning patient chart.
Add additional temporary supporting staff: In this model we typically see that the staff can ensure that the legacy system is properly maintained and all patient information is successfully managed, whether the organization brings temporary staff on board or simply uses resources from other departments to help during the few months after adoption.
Test conversion: Testing the converted information in the new system is extremely important, as with any major system change, especially those with data conversions. These tests must be performed by the staff who will be actively be using the new system, not just by the technical folks. Feedback must be provided once the tests have been completed and all the issues must be addressed prior to going live.
Maintenance of dual systems: The inability to efficiently report on all the data as a whole is a challenge that most organizations face when having their data stored and maintained in two systems. Use of methods that may require temporarily warehousing data from both systems in a central location to enable reporting on all of the data is necessary in some cases.
Data conversions can have a significant impact on a new system. If the workload is such that the staff is unable to perform efficiently in the new system, it can cause challenges for the organization and lead to further issues. Conversion must be well planned out and involve all the appropriate parties to ensure a successful transition.