As part of creating a patient plan, you need to send in the payor that the patient has a plan with. As you must send in a Silna payor id, one of the items clients must solve is how to convert their own representation of a payor into a Silna payor id. There are three main strategies for achieving this which I will explain below.

​
Mapping your Payor Ids to Silna Payor Ids

The most accurate way to transform your payor ids to Silna payor ids is to build the mapping internally. If you initially onboarded to Silna through the web app, one strategy which aids in this process is to bulk export patient plan data from Silna and join it with your internal data to determine the mappings. The downsides to this as it is more tedious and for net new payors, you will have to maintain a process to update your internal mapping.

​
Using Clearinghouse Payor Ids

If you have adopted a clearing house standard like Availity, Office Ally, ClaimMD, etc to map your payors you can use our Get Provider Payors endpoint to transform these ids into Silna Payor Ids. If you have Ids which don’t exist in a standard, this API allows transformation of those ids into Silna Payor Ids.

The downside of this approach is that there are some clearing house standards which have the same id used across distinct payors. For example, in the ClaimMD standard, all payors in the Centene family have the same id (https://www.claim.md/payer/68069). So, if you sent us a GET Provider Payors request with this identifier we would return all the payors in the Centene family which doesn’t help in the identification process. To resolve this, you would either have to create a mapping internally or create overrides for the Centene family of payors.

Another downside is that sometimes you might not map payors the same way Silna maps payors. This happens when you map a payor to the payor id used for administering benefits. For example, if you provide behavioral health benefits, you might use Magellan’s payor id for BS California, BCBS Texas, or Medicaid Idaho since Magellan handles claims for these payors. However, the patient doesn’t have a plan with Magellan and we do not map Magellan Payor Ids to these payors.

​
Using Payor Inference

If you collect insurance cards for your patients, you can use our Payor Inference API to send an insurance card and we will tell you the patient information on that insurance card (including the Payor). If you don’t have insurance cards, you can also just send us the payor name in your system and we will attempt to determine the corresponding payor in our system. Under the hood, this API uses the same rails that our insurance card upload in the web app uses.

The downsides to this API is that it is asynchronous, so you may have to wait up to a minute to receive your answer.

​
Recommendation

We have customers using all three approaches and we believe that customers have the most success when they use a combination of these solutions. For example, you can create an internal mapping and handle the n + 1 case by using payor inference when the mapping is not found. Please feel free to reach out to the Silna team to discuss what approach may be right for you!