Many healthcare analyses involve the concept of “patient attribution”—in other words, linking a patient to the provider responsible for their care. For example, you might want to know which primary care physician or clinic has been managing a patient’s health to properly assign the rewards when that patient has a good outcome (e.g., good medication adherence, or lower-than-expected spending over some period) or the responsibility for a bad outcome (e.g., a readmission, or a preventable emergency room visit).
The fundamental challenge of attributing a patient to a provider arises from the possibility that there might be multiple candidate “attributee” providers. So we must sort through the evidence in favor of each to choose just one. At its core, then, attribution represents a ranking system: a series of comparisons, resolved in order, until a clear winner is determined.
These ranking systems can become complicated as they seek to reach an appropriate conclusion across the breadth of real-world scenarios involving patients, providers, and their interactions. For example, there is often a tension between a model’s ability to quickly pivot to a new provider when appropriate and its capacity to be patient and avoid inappropriate pivots. In addition, it can be difficult to extend the algorithm to handle new corner cases while not disturbing its carefully calibrated handling of previously considered scenarios.
Finally, patient and provider circumstances change over time in ways that influence attribution. That is, when done properly, the “winning” provider in an attribution model is likely to change over time, and so we will want a way to model this relationship dynamically.
An example will help illustrate these challenges and provide an opportunity to discuss solutions.
Consider an exercise to attribute patients to a single primary care provider (PCP) at any given moment in time. An initial sketch of the algorithm might look like this:
This seems sensible so far. But what if a patient’s regular provider is temporarily unavailable, so a colleague sees the patient instead? The rule above would switch patients after just one visit with a new provider, which is probably not what we would want to happen.
Therefore, we might want to add some inertia to a prior attribution so the patient isn’t bouncing between providers. A refined rule might incorporate the number of visits with each candidate provider as the first ranking criterion, then use the date of the most recent visit with each only as a tie-breaker.
But maybe this rule creates too much inertia. Consider a scenario in which the patient has a regular primary care physician, Dr. X:
By the end of 2020, the refined rule would still attribute the patient to Dr. X, which is likely not the desired interpretation.
We can get the correct result in this scenario by tweaking the attribution logic to add a cap to the count of visits used in the ranking logic. For example, using a cap of two visits, by the end of 2020 the patient would have accumulated two (countable) visits with both Dr. X and Dr. Y, and then the tie-breaker of most recent visit would attribute the patient to Dr. Y. In fact, this switch would happen after the second visit in 2020 with Dr. Y.
Now, if we had access to a registry of actively practicing PCPs in the local market, we would likely want to be even more aggressive with switching attribution away from departed providers. If the reason the patient in our example stopped seeing Dr. X was because Dr. X moved out of state, for example, we might want to dis-attribute the patient to Dr. X immediately upon the patient’s first visit with Dr. Y, rather than wait for a second one.
Particularly common with primary care, health plans may assign patients to providers. Depending on the circumstances, this administrative assignment can be anywhere from very weak to very solid evidence that the assigned provider is truly the appropriate attributee.
Let’s say that the administrative assignment of the patient in our example is purely pro forma—e.g., patients are randomly assigned a PCP at the time of their enrollment and face no financial penalty for seeing a different PCP—and so should carry very little weight in our attribution model. We’ll use it as a default attribution in the case where the patient has no visits with any providers.
Considering all of the above, the final rule might look something like the following:
An important characteristic of attribution is that it changes over time. In the above example, the patient was under the care of Dr. X for all of 2019. Any retrospective analysis of performance over 2019—even if that analysis is performed in 2021—should assign performance success or failure in 2019 to the patient’s physician at the time, Dr. X, and not to their “current day” physician, Dr. Y. All this makes the timeline data structure an excellent choice to represent patient attribution.
The following timeline structure represents the inputs and conclusions from the example above:
To implement an attribution rule like this—e.g., in a SQL query—it’s useful to think of three distinct categories of inputs:
To start, for any given patient, at any desired moment in time, the set of interactions between that patient and providers can be used to generate the list of candidate providers.
Then, for each candidate provider, a record (e.g., a database table record) can be constructed with the individual pieces of information used in the attribution logic. So, sticking with our example above, we might want a record for each candidate provider with the following fields:
(Note that these records would be generated for each patient-provider-date triple, for each date on which we wanted to determine the patient’s attribution status.)
Once these records are collected, all that remains is to sort them in the correct order based on the attribution algorithm and select the top-ranked record as the “winning” provider.
Finally, the process of attributing patients to exactly one of a set of candidate physicians can be generalized in two ways:
The essential property is that the relationship is exclusive (i.e., there can be only one at any given time); beyond that anything can be swapped into the roles of attributed entity and candidate attributee. For example:
In other words, if you can frame the question as “Out of many possible options, which, at this moment, is the single best one?” there’s a good chance you’ve got a problem that an attribution mechanism can solve.
Ursa Health’s no-code analytics development platform, Ursa Studio, includes tools (e.g., the Attribution Timeline object) that allow users to implement sophisticated business logic like this in a few minutes. For more information, click here, or email us at email@example.com.