We deal with a lot of data here at Azara. I mean a lot of data. We gather information from hundreds of unique sources and collate this data into the numerous reports and measures that our customers use in the DRVS application. In a perfect world, our reports would be completely updated in real-time; as soon as you put diabetes on a problem list that patient would show up in our diabetes CQM denominators. Of course, that’s the ideal case and none of us live in the perfect world. Data latency remains an important challenge for us and for reporting and analytics in general. Let’s take a deeper look at how we tackle some of these problems at Azara.
Those of you who have done an implementation with us know that we install a “connector” on your servers that send data to our servers on a regular basis. These connectors can be configured in a variety of ways; most often they’re setup to send data to us once a day, usually in the middle of the night to avoid taxing client systems during the day. Some client systems have quite a bit of data, and it doesn’t make sense for us to send all the data every night, so we need to capture what we call “the incrementals”. These are new encounters, diagnoses, medications, and so on, that were created or modified since the Azara last data pull, usually the previous evening. There’s a big difference between sending tens or hundreds of new appointment records in a night, as opposed to the thousands or hundreds of thousands of historical appointment records that may be in your system.
On the Azara side of things, we also need to take steps to limit the scope of how much data we’re processing. We have hundreds of measures which have been processed for millions of patients across hundreds of reporting periods, and as many of you know, some of these measures can get quite complicated. It would be great to reprocess all these measures for all reporting periods every time we load new data, but we simply don’t have the time or computing power for that, so we need to thoughtfully pick and choose what gets processed and when. Today we process the “current” reporting periods every week, so on the weekend of February 24/25, for instance, we will process measures for TY February 2018. We usually switch over around the middle of the month. Of course, there are exceptions to this rule. During “UDS Season” we reprocess UDS specific measures for the relevant calendar year period almost every night, and as many of you know from working with our support team, we often do ad-hoc reprocessing for scenarios where historical data was cleaned up in the EHR or mappings were updated.
While clinical quality measures get processed on a weekly basis, our registries and Patient Visit Planning reports need to be more up to date. We handle this by doing nightly processing for specific data elements such as most recent A1c, blood pressure, chronic conditions, etc. Furthermore, we try to limit our processing to patients for whom we’ve received new data since the last time our processing ran. There’s a big difference between updating the most recent blood pressure for 100,000 patients versus just the 1,000 patients who had new data loaded in the past day. Identifying these “incremental patients” can be quite tricky, especially given the breadth of data that Azara collects. Furthermore, it’s not just clinical data that can cause our reports to change - updates to reporting logic or value set content can change things without receiving any new patient data. If a new ICD-10 code is added to the diabetes value set, that may change many patients’ status as a diabetic in our system, even if we didn’t receive new data about them.
People often ask about how we handle performance issues given the amount of data we work with. Sometimes the answer is to write faster or more efficient code or to purchase additional computing power, both of which we’ve done many times over the course of our history. Hopefully, this post exposed and explained the third option that we’ve exercised - being creative and strategic with our operations, turning things on and off depending on the current needs of the business and individual clients. Of course, this too comes with an added cost. The additional rules and selective processing add to the burden of operations management, so at the end of the day, we need a person to sit at the control board and orchestrate the resources. If you know someone who loves healthcare and data, we’re hiring!