Sharp Revenue Tools API Guide

This is used when you have all the information about the patient's insurance. Use product ID of 1.

This runs the top level of the patients credit report and is utilized in Insurance Discovery. It will return information such as address, gender, SSN. Use Product ID of 2

When you don't know what insurance the patient has, you can run this. Using as much information you can provide this will fish for insurance. Use Product ID of 3

This is used when you have the old Medicare member number and you need the new member number. Use Product ID of 5

There are many API endpoints on the server to choose from and use. While the Swagger provides information on how to use the API’s, we encourage you to contact our developers with questions.

There are many API’s used for patient searching within the system. This utilizes the patient management feature of Revenue Tools. If the system you're integrating with is an EMR-type system that manages patient information, much of the patient-specific API’s may not be relevant to you.

The root object returned by many APIs contains a property called ClaimRevResultId, which serves as the primary key for Revenue Tools. This ID is used in APIs for checking statuses or retrieving specific benefits.

To run Revenue Tools with the mentioned products, use this API:

POST: /api/SharpRevenue/v1/RunSharpRevenue

{
        "practiceName": "My DEMO Account",
        "requestingSoftware": "Post Man",
        "npi": "1234567890",
        "practiceState": "OK",
        "subscriberId": "string",
        "patientFirstName": "Heath",
        "patientLastName": "Varner",
        "patientGender": "M",
        "patientSsn": "778956541",
        "patientState": "OK",
        "patientDob": "2023-11-03",
        "productsToRun":[1],
        "payers": [
        {
            "isRevenueToolsPayerId": true,
            "payerNumber": "00015",
            "payerName": "BCBS of Indiana (Anthem)",
            "subscriberNumber": "M45695321"
        }]
}

Much of the first part of the request contains housekeeping properties:

• AccountNumber - Automatically set if left blank.
• RequestingSoftware - Enter any value you'd like.
• Client ID - Can be left blank; it is a legacy property.
• UniqueTransactionNumber - This should be unique to your system. The system will create one if left blank.
• ProductsToRun - An array of all the products you'd like to run for this patient.
• IsRevenueToolsPayerID - this is set to true if using payer ID's from the Revenue Tools portion of the processing system. If you're using the Payer ID that is typically on a claim, the system has to lookup the mapping for that payer. In that case you'd use False in this location. If an EMR is setup to send claims to ClaimRev, that EMR will have claim payer ID's setup with the insurance information for that patient. That is when this value should be false.

Note: The PreAuthorization product is still in development, may not function currently, and could change in the future.

See Swagger for response details.

This API returns the Sharp Revenue object if you need the results again.

POST: /api/SharpRevenue/v1/CheckTransactionStatus

{
  "accountNumber": "string",
  "uniqueTransactionNumber": "string"
}

* uniqueTransactionNumber is the number that comes back on the results of /api/SharpRevenue/v1/RunSharpRevenue in the property MappedData.TransactionId. Here is an example:

 ...
    "responseMessage": "success",
    "retryLater": false,
    "isFatalError": false,
    "mappedData": {
        "transactionId": "VarnerHeathDEMO120250108095731294",
...

Same as RunSharpRevenue.

The RunSharpRevenue api returns a property called claimRevResultsId, this is the key to the results in the system. You can always pull that back out using the API

GET: /api/SharpRevenue/v1/GetEligibility?sharpRevenueRtEligibilityObjectId=claimRevResultsId
Note: this is a GET call, there is no body and should be set to none in postman.

Same as RunSharpRevenue.

Note that the test API's are just to get started, switching to production with real data is important and will help complete your integration.

The demographics part of the service will typically return the info that was passed to it. For example, if the caller requests data on John Smith of San Pablo CA with a date-of-birth of 1/23/1974, that is exactly what the service will return. However, the exact behavior will depend on the person’s last name:

• Last name starts with “B” – the SSN will be returned as an arbitrary test value.
• Last name starts with “C” – the date of birth will be returned as an arbitrary test value, and arbitrary red flags and warnings will be returned.
• Last name starts with “D” – the state will be returned as “KY”.
• Last name starts with “E” – an error will be returned.
• Last name starts with “F” – the name, address, SSN, and DOB will be returned as arbitrary values, yielding a low confidence result.
• Otherwise – the values from the request are returned without modification.

Note that arbitrary landline and cell phone numbers will be added to all non-error demographic responses.

The behavior of the credit (“self pay”) part of the service is based on the first name:

• First name starts with “A” – acceptable credit is returned, along with employment info.¹
• First name starts with “B” – poor credit is returned, along with a past-due trade account.
• First name starts with “C” – various credit info is returned, including employment info, two trade accounts (one installment and one revolving), a collection account, and a public record.
• If the first name starts with a different letter, the second letter of the first name will be used as above if it is an “A,” “B,” or “C.” For example, a person named “Daniel” would have acceptable credit and employment info, but a person named “Doris” would have no credit record returned. This allows the credit mock service to be used without conflicting with the eligibility mock service described below.
• Otherwise – no credit information is returned.

¹ Note that available employment information is usually very sparse. The employment data returned by the mock service is modeled on actual data returned by our vendors, and not all fields will be populated.

The behavior of the service is largely dependent on the name of the subscriber / guarantor:²

• Note Use Payer Payer Number: 00015 and PayerName:BCBS of Indiana (Anthem) if using the claim payer id use '00630' and set the property “isRevenueToolsPayerId” to false
• Subscriber first name starts with “H” – return Active coverage if subscriber id is present, otherwise return an AAA 72 validation (indicating a missing subscriber id).
• Subscriber first name starts with “I” – return Not Found response with an AAA 42 validation (indicating service temporarily unable to respond); a different AAA validation code can be sent if the first name contains a hyphen followed by the code (for example, a first name of “I-41” will cause a AAA 41 to be returned).
• Subscriber first name starts with “J” – return Active coverage with subscriber id of “908080808RW”.
• Subscriber first name starts with “K” and last name is equal to payor name – return Active coverage with subscriber id of “99999999”.
• Subscriber first name starts with “K” and last name is not equal to payor name – return Not Found.
• Subscriber first name starts with “L” and last name is equal to payor name – return Inactive coverage.
• Subscriber first name starts with “L” and last name is not equal to payor name – return Not Found.
• Subscriber first name starts with “M” – return Active coverage with a full address for the payor.
• Subscriber first name starts with “N” and a member id not ending with ‘T’ is sent – return a corrected Medicare member id which substitutes a ‘T’ for the last letter.
• Subscriber first name starts with “N” and a member id ending with ‘T’ is sent – return Active Medicare coverage.
• Subscriber first name starts with “O” – return Unspecified coverage.
• Subscriber first name starts with “P” – return Active coverage, but with an arbitrary first & last name and arbitrary DOB – the resulting record is thus low confidence.
• Subscriber first name starts with “Q” – return Active commercial coverage with deductible info.
• Otherwise – return Not Found.

² Note: The behavior described above depends on the subscriber/guarantor’s name matching specific conditions.