Latency is a major theme that arises when we trace our customers’ DRVS data quality. As DRVS extracts data from the EMR on a daily basis, there is always an inherent latency in the data that is shown. We aim to achieve what we call “zero-day latency,” which means data entered in the EMR the previous day displays in DRVS on the current day. However, sometimes a combination of IT infrastructure choices, DRVS data extract timings, and DRVS reprocessing schedules stretches this latency out much further. Though it may not significantly impact the results of annual or quarterly clinical quality reporting (such as UDS and Meaningful Use), it will affect the accuracy of operational reports, such as the Clinical Registries and Patient Visit Planning.
How Data Latency Occurs
Let’s imagine that your EMR has reverted back to the days of the dreaded paper chart, and you have a system setup through which reporting can be accessed by calling medical records. On Monday, a diabetic patient visits and receives a point of care A1c test. In a “zero-day latency” world the paper chart complete with the A1c result would get sent to medical records and filed away by Tuesday. So if you wanted to find a patient’s most recent A1C result, you could call medical records on Tuesday and they would tell you Monday’s testresult.
But maybe medical records is off-site and you require – in order to avoid files getting lost – that each chart be photocopied before being sent to medical records. So if you have a Monday visit, the visit’s chart would be put into boxes on Monday night, loaded onto a truck, and shipped to a copy center. On Tuesday, the copy center would open up the boxes, photocopy each chart, and place them back in the box. On Wednesday, the charts would be sent to medical records and they would begin sorting and filling away all chart copies. Finally, all the charts get put away and are ready to be accessed Thursday. If you were to call medical records on Tuesday and ask for the most recent A1c result, they would not be able to tell you about Monday’s result because it had not yet been filed. Instead, they would give you the most recent A1c that they have, which could be months old.
This is why latency affects data quality in DRVS. If DRVS is set up to extract data from a reporting server (photo copy) that is hosted by an outside vendor that receives only nightly updates (off-site medical records), the most recent result that displays in a DRVS Clinical Registry or Patient Visit Planning Report might not be the most recent result for that patient in the EMR.
What you can do about latency
When a health center is deciding which patients to contact for follow-up or for planning another visit, the latency can really make a difference. Having “zero-day latency” in DRVS allows you to get the most out of the reports and helps build trust in the data. So what can you do about it? Below are four steps to reducing your DRVS data latency.
- Determine your center’s typical DRVS data latency. Submit a ticket to email@example.com that asks for the frequency of your DRVS data latency. You’re all set if DRVS support tells you that your center has “zero-day latency.”
- Work with IT to have DRVS pull from your “production environment.” This is server that your EMR lives on, and it will always have the most up-to-date data. Though there may be performance implications to moving to a production extract, these are easily avoided, and having the conversation with IT and DRVS support could be well worth it.
- Identify a “data readiness time” for your center. If the last patient exits your center at 5 PM each night, and providers normally finish charts by 8 PM, your “data readiness time” is 8 PM. Let Azara know this, as we may be pulling the data at 7 PM, which introduces a day of latency that can be avoided by simply adjusting the data pull to sometime after 8 PM. (Note: processing schedules vary for different clients)
- Fix connectivity breakdowns quickly. Though it’s not the same as typical latency, a breakdown in connectivity between Azara and your center’s EMR will have the same effect: out-of-date data. Though DRVS support will contact your center when connectivity breaks down, being proactive with notifying Azara of IT infrastructure changes, or quickly responding to requests for assistance, will speed the process.
All of us at Azara want your data to be as “fresh” and as up-to-date as possible. We understand there are legitimate causes of data latency, but by working closely with your Azara support team, you can be assured that your latency is reduced to a minimum.
Samuel Bar is an implementation specialist at Azara Healthcare.