Rollouts

Rollouts are the process of gradually deploying new software over a extended period of time. They allow you to manage changes, ensure stability, and catch any potential issues early on. At Slingshot, we support (and encourage) the use of rollouts for our API.

In fact, we allow you to configure rollouts without any code changes so you can control how quickly you want to deploy Slingshot’s analyses across your claims. You can rollout by Criteria, Plan, Provider, and Diagnosis.

​

Rollout by Criteria

For each rollout, you must specific the criteria you would like to rollout. Each criteria has a specific set of DRG codes or Diagnosis Codes it supports and can only be rolled out for them. If you wanted to rollout Sepsis3 Criteria you could not apply it to I21.9 (Acute Myocardial Infarction, Unspecified).

​

Blind Rollouts

Blind rollouts allow you to view how Slingshot’s analyses would have performed on your claims without returning an output for your system to take action. This is useful for testing and validating Slingshot’s analyses before you actually deploy them.

​

In Practice

When a claim is submitted to Slingshot’s validate endpoint, we will check to see if the claim matches any of the rollouts you have configured. If it does, Slingshot will return a NoDetermination. This means either Slingshot has not evaluated the the claim as it was in the control portion of the rollout or that the claim is in a blind rollout group and was evaluated but not returned to your system.

​

Conflicts

Because of the fine grained capabilities of Slingshot rollouts, there are scenarios where your rollouts may have conflicting configurations. For example, if you have a rollout by Diagnosis Code and a rollout by DRG, you may have a claim that matches both rollouts. For such instances, the rollout with the most specific granularity will be used. In this case, the rollout by Diagnosis Code would be used. The order of priority goes as follows: Diagnosis Code > DRG > Provider > Plan.