Questions and Answers > Understanding the Redox Claim Data Model
Questions and Answers

Understanding the Redox Claim Data Model

When do I need to use the Claim Data Model?

The Claim Data Model is used for transactions between a healthcare provider and an insurer detailing the services provided. Claims-related transactions between a payor and provider can include: pre-authorization for a patient, a submission of a payment request, the status of that submission, the details of the payment, and the explanation of benefits (EOB).

Currently Redox supports Claim.Submission, which is used to send a payment request, typically from a healthcare provider to an insurer. Redox also supports Claim.Payment, which is used send a payment notification, typically from a payer to a healthcare provider, but it may be used in other situations where funds are transferred from one party to another.

When and where can the Claim Data Model be found?

Many EHRs have support for the Claim Data Model in order to facilitate interactions with insurers. Typically this is facilitated through the 837 and 835 X12 transactions.

Does this mean Redox can integrate with Practice Management Systems as well as EHRs?

We can support integrations with practice management systems as well as other revenue cycle specific products. If we have not already integrated with a specific system that you’re interested in, we’re happy to speak with the vendor and identify their integration capabilities and how we could support a connection with them via Redox.

Does this mean Redox can integrate with insurance companies or clearinghouses?

We can certainly integrate with insurance companies and clearinghouses, but these are not native integrations that we could immediately activate for you. We would require that you have a contract/business associates agreement in place with the organization that allows you to connect and integrate with them.

Are claims messages sent in real time?

Technically claims integrations could be real-time, but in practice most organizations will run an overnight or end of day batch job to trigger messages. In these scenarios, we will still receive the messages and send them downstream to you in real time, but typically health care organizations are not sending ad hoc claims messages throughout the day.

Do you support applying business logic to claims integrations?

While we do support filtering within our API to reduce unwanted messages (e.g. only pass along messages from a specific department or messages with specific charge codes), we do not currently support applying comprehensive business logic or rules to our integrations.

How does the Claim Data Model differ from the Financial Data Model?

Both the Claim and Financial Data Models deal with fiscal aspects of a patient’s care, but differ in several ways:

  1. Claim messages are generally roughly the summary of all the patient’s Financial charges in an account, with Claim being the amount that the hospital wants to actually bill that is sent to an insurer after care is complete.
  2. Financial occurs on the fly during a patient’s care, whereas Claim is typically sent or received once after an admission or encounter is concluded.