This blog series has been aimed at outlining methods and tools to help make working with claims data a bit more accessible. In the first two parts of this blog series, we discussed methods to profile and prepare your claims data. Next, I will propose a strategy to translate your cleaned dataset into something that is clinically relevant.
Claims data consist of financial transactions in their raw form. Each transaction represents a request for payment for a clinical service rendered. To be consistent with my prior work, I’d like to offer a forced metaphor. Claims data and your weekend grocery receipt are similar in more ways than might be obvious. Afterall, a grocery receipt is essentially an accounting of financial transactions. Let us suppose that I gave you the receipt from my weekend grocery trip.
So here is the big question: what was I planning to cook? We’d have to derive a meal out of the items on the receipt, since no one item represents a cohesive meal alone. And despite what my toddler says, those cosmic brownies are not a meal.
Taking this back to claims data, each row is a transaction where money was exchanged for goods (groceries) or a service (medical care). The act of figuring out my meal plan is analogous to deriving something like inpatient admissions from the claims data. Admittedly, this is a bit ridiculous, but below is claims data represented in a receipt format. To illustrate, let’s use the below data for the remainder of this blog, so I present to you, my clinical receipt:
I ask the same question: What meal am I cooking? More precisely, what kind of care is being rendered? Although some of these items could be distinct encounters, they cannot be evaluated line by line. You must boil this information down into something more clinically tangible. In this case, we have a patient who visited an ER and was subsequently admitted to an inpatient setting. This scenario includes a few professional CPT codes, nursing charges and a few labs. When we talk about deriving these clinical events, we tend to talk about “episodes” or “encounters”. For that reason, I’m going to say that we are applying “episode logic” to our raw claims data which helps derive the clinical story from the financial transactions.
Episode logic is a loaded concept. Frankly, the exact type of episode logic you want to leverage will heavily depend on your use cases. For now, I’ll focus on a particular type of logic that outlines how ER-IP episodes can be constructed from the above transactional data. Unfortunately, our clinical receipt is missing an important data element, so I’m going to add it quickly. No, my grocery metaphor isn’t breaking down. Yes, I know what I am doing…I promise. To prove it, I am also going to color code these events to help with the next illustration.
Now that we have dates of service, we can start visualizing the patient’s journey on a timeline. Let us start with the three codes that are colored in the above receipt. I like to call these types of codes episode anchors. They place a patient at a distinct time and place, which we can use to start building the clinical narrative. There is an emergency room (ER) admit charge on 3/1, an inpatient (IP) per diem charge on 3/1 for 2 units, and an IP subacute room charge on 3/3. Below is a timeline, marked with these anchor codes.
You might see this and think that your patient had two distinct hospitalizations, one on 3/1 and a second on 3/3. However, if you recall the above receipt, none of these anchor codes are to be considered in a vacuum. We need to connect a few more dots before we can calculate these sorts of metrics.
To do so we need to understand the concept of units. Units represent different concepts depending on the code that is billed. Units can denote days, blocks of time, or even units of blood. In the case of the “0120” inpatient code, each unit corresponds to a single day. This means we can begin to talk about concepts like length of stay. With that in mind, here is what the timeline looks like for the anchor codes that I have highlighted above.
We’re starting to get a picture of where the patient was during this three-day span. Next, we will add in the rest of the codes. Rather than color coding the remaining codes, I’ll use data labels.
Great, so effectively, we’ve graphed our entire clinical receipt here. However, it still looks like two distinct inpatient admissions, and that doesn’t feel quite right. The next step is to collapse these things into a cohesive episode. For our purposes, we can collapse this into a single continuous episode. In this case, I’m going to be combining the ER admission, inpatient bed charges, and the subsequent sub-acute charge. We’ll collectively call this our single ER-IP admission episode.
Pretty simple, right? If you remember from earlier blogs, claims are moving targets. I’m going to illustrate how episode logic might react to claims data over time. We’ll continue to talk about inpatient events because they tend to have a multiple day duration and they are useful for illustrating complicated patterns of care. However, remember that these episodes can be constructed from single day clinic visits, lab draw visits, or any encounter type of interest. For the next few examples, I’m going to shed the receipt concept and go with a simplified table.
First, let’s look at a simple situation where we have two inpatient stays, one from 3/1-3/4 and then a separate inpatient stay from 3/6-3/7. This scenario would typically be called a rapid readmission, which is an event of clinical interest.
Anything we derive from claims data may evolve over time as new data is received. Updating your dataset will likely impact previously built episodes. With that said, suppose we receive a claim that suggests a continuous stay rather than a rapid readmission. This simply underscores that you will want a relatively complete set of claims data before drawing any conclusions based on episodes.
Admittedly, this was a lot of work to distill a single hospitalization out of a mess of claims records. Similar logic would be required to extract other episode types from the raw data. Depending on your needs, this can be quite complicated, however it is worth the effort. Some form of episode logic is imperative if you’re looking to distill common claim metrics such as length of stay, cost per visit. Without it, you’d likely be over-reporting utilization counts and under-reporting metrics like length of stay.
In summary, I’d like praise you for reading a whole blog about something as boring as claims transactions and I’d bet it’s the first time you read something attempting to relate grocery receipts to claims data! If anything is taken from this, it’s simply that claims data requires some cooking before it can be properly digested.
