Many health systems have one main EMR used as the source of truth for patient data. However, in today’s merger and acquisition environment, organizations must be prepared to combine data from different EMRs into a cohesive story so that clinicians and operations are able to continue high levels of care and decision-making. Similarly, larger health systems may have a constant state of multiple EMRs to consider, thus the consistency of data from one system to another is not just a short-term consideration and investment, but a long-term one as well.
When data is combined from different EMRs to present a larger data set across multiple facilities, there are oftentimes three main points of failure: data entry, database, and visualization. To mitigate these points of failure, focus on these three principles:
Different EMRs offer different configuration options. This seems like an obvious principle; however, its implications are far-reaching when it comes to data gathering. With different configuration options comes different data output, as some systems may have data points that others do not. Recognizing different configuration opportunities in the systems to understand where parallels can be drawn to create similar enough output for data consumption and analysis is key to being able to normalize data across systems. Involving subject matter experts (SMEs) from each of the EMRs and allowing collaboration and discussion between them will enable your organization to have a better understanding of configuration options that may get the systems as parallel as possible. Attempting to base one system’s configuration on another’s (or assuming they are similar enough to just mirror build from one to another) will limit one or multiple EMRs. Instead, make use of the SMEs to work together to understand the different configuration options to make the best use of the native functionality within the systems themselves. When the best use of a system’s native functionality is in play, users are more likely to complete the needed workflow to gather the data. If instead multiple work-arounds are used in a system in order to mimic a different system, these workflows will not feel intuitive to users and they will be less likely to follow them (and then the data will not be there either).
Different EMRs may use different terms to mean the same things and/or the same term to mean different things. Again, it is important to get system SMEs involved to work together on translating one system’s terms to another’s. Putting forth the effort on the front-end will allow the data to look more seamless to those viewing the data, as well as prevent confusion around what the data actually means and represents. Users should not have to wonder what a term means or whether it means different things in different systems – that effort should all be completed prior to individuals receiving the data so that they have a streamlined and consistent data experience. The term that the user sees should be an agreed-upon term, typically established by operations, to represent the data point. On the back-end, that data point may be referenced differently depending on the EMR, but data consumers should only have to be familiar with one term, regardless of how much work went into getting the data to be consistent on the back-end.
Given all of the analysis and translation that goes into data to get it normalized, it is essential to involve those SMEs in the validation process to ensure the intention transformed correctly to the output. Validation starts with workflow. Ensuring the workflow that was put into place is intuitive to users and meets regulatory and operational needs is only the first step of validation. The SMEs will then need to look at how the data is pulled into the database to ensure there are no unintentional gaps or manipulations that happen in the data pull and filing. Finally, SMEs will need to look at the visualization layer (i.e. what the user sees) to ensure that nothing happened to the data in the layer between the database and the visualization. Additionally, involving users or operations to perform validation once data is ready for consumption is key. Users will oftentimes find anomalies in the data because they are looking for certain data points, correlations, interactions, etc. Having a subset of users themselves look at the final product, prior to its release to Production/Live, will offer the broader pool of users a better experience, as these issues can be addressed prior to the product being introduced more holistically.
When troubleshooting any issues or questions that might arise from individuals looking at data across multiple EMRs, be sure to check the three main points of failure:
Depending on where the cause of the issue lies, use the main principles to address what is needed:
Our CereCore experts have deep subject matter expertise from supporting and advising hospital systems using multiple EMR systems. After merger and acquisition activities, many hospitals choose to operate in a multi-EHR scenario instead of the rip and replace option. Using multiple EHRs is possible, especially with these practical principles in mind to better understand systems and to help put patient care first.
Consulting Architect, Epic Services, CereCore
Consulting Architect, Epic Services, CereCore