Claims & Reimbursement

The Claims and Reimbursement (CR) Domain Message Information Model (DMIM) encompasses the financial interactions between a healthcare product or services Provider (e.g. individual healthcare practitioner, healthcare facility, pharmacy, medical goods and supplies purveyors, etc.) to an Insurance Carrier (e.g. jurisdictional medical services plan, insurance organization, workers compensation organization and/or their agents).

An Insurance Carrier may delegate performance of this function to an Adjudicator (agent of the Insurance Carrier). Subsequent discussions only note Provider and Adjudicator (not Insurance Carrier).

These interactions include Query Eligibility, Authorization, Coverage Extension, Pre-Determination, Invoice (claim), Adjudication Results, Payment Advice and Statement of Financial Activity (SOFA).

The 2 core classes referenced in the DMIM are the FinancialTransaction (XACT), cloned as the PaymentRequest, PaymentIntent and Payment and the InvoiceElement (INVE), cloned as the InvoiceElementGroup, InvoiceElementDetail, AdjudicatedInvoiceElementGroup, AdjudicatedInvoiceElementDetail, AdjudResultsGroup and AdjudResultsInvoiceElementRef.

To generate an Invoice (request for payment and adjudication), a PaymentRequest (a FinancialTransaction in RQO: request mood), InvoiceElementGroup (an InvoiceElement in RQO: request mood) and an InvoiceElementDetail (an InvoiceElement in RQO: request mood) are created and related through Act Relationships and supported by a number of participations (e.g. Covered Party, Coverage, Payor, Payee). An invoice message can be made up of groups of components that are independent requests for payment and adjudication. The items included in a group are adjudicated interdependently.

A submitted Invoice is sent to the Adjudicator identified in the message control wrapper with a Payor identified through the Debit to the A_AccountPayor CMET. The Adjudication Result is communicated as a PaymentIntent (a FinancialTransaction in PRMS: promise mood) and the AdjudicatedInvoiceElementGroup and AdjudicatedInvoiceElementDetail (InvoiceElements in EVN:event mood) that describe the invoice items (possibly modified) as paid with a relationship to the original submitted item. The adjudication results codes are related to the Financial Adjudication (ADJUD) class cloned as AdjudicationResult also in the EVN: event mood.

Finally, the payment (funds deposited, cheque created) is communicated as a Payment (a FinancialTransaction in EVN:event mood).

• Coverage Confirmation (Eligibility, Authorization):

  Prior to performing a billable act and invoicing, the Provider may attempt to determine eligibility for coverage for a specified patient (EligibilityQueryRequest). This is a simple verification to determine if the Adjudicator is aware of the patient and the patient has some base level of coverage. In addition, the Provider may request specific product or service Authorizations from the Adjudicator (AuthorizationRequest).

  The AuthorizationResult will itemize the items authorized much as the invoice adjudication result lists items as adjudicated. Limits to the coverage are specified as AdjudicationResultsInformation items (OBS: observations) as pertinent information to the AdjudicationResult (ADJUD class). A positive Authorization response (i.e. authorized) may also indicate that the payor has set aside funds for the subject of the Authorization (e.g. medical procedure).

• Invoice:

  The PaymentRequest allows for a grouping of InvoiceElements and reflects the request for payment of a specified monetary amount. The PaymentRequest indicates "Please Pay" and ties to a root InvoiceElementGroup; the items (details or groups) included in each InvoiceElementGroup must be adjudicated together. In other words, each InvoiceElementGroup separates independent billable items.

  The InvoiceElement (both group and detail) are the elements of an Invoice that need to be adjudicated in order to determine any payment. There are 2 types of InvoiceElements: a group and a detail. The InvoiceElementDetail identifies the pricing for a line item such as a drug, medical procedure, durable good or other billable item including adjustments (e.g. taxes, discounts, surcharges). The InvoiceElementGroup allows for the grouping/collection of InvoiceElementDetails and/or other InvoiceElementGroups to make up a logical billable item. For example, a Pharmacy dispense may have a group with 2 details, one for the drug cost and the other for the dispense fee. Both must be present and ate grouped with an InvoiceElementGroup. See invoice type grouping example diagrams in the Domain Description.

  When coordinating benefits the portion of the previous adjudicator(s)'s results that were placed in the A_InvoiceCoordination CMET are included with the message.

  Concluding, an Invoice is made up of one PaymentRequest (Please Pay), connected to a root InvoiceElementGroup (to which a set of participations and act relationships are connected to provide information applicable to the whole invoice) that contains one or more InvoiceElementGroups and InvoiceElementDetails sets. See invoice type grouping example diagrams in the Domain Description.

  An Authorization may have been obtained for an A InvoiceElementDetail or InvoiceElementGroup that is specified by the InvoiceElementCrossReference.

  Included in the messages are the identification data for each of the participants, including Providers organization, practitioner organization, patient(s)/covered party, policy holder, Payor, Payee, and Contact Party individual. The Payor is the party specified as financially responsible for the Invoice and the Payee the party that will receive any payment. Both of these relationships are noted against the PaymentRequest. Patient(s) are identified as the Covered Party for the root InvoiceElementGroup. There may be a single patient or an itemized group with individual insurance information.

  Insurance information is included in the PolicyOrAccount act. Three major roles for an insurance policy are the CarrierRole, PolicyHolder and CoveredParty. There may be multiple CoveredPartys for a single insurance policy, with the CoveredParty role describing why the patient is covered by the insurance policy (e.g. spouse of PolicyHolder). Multiple insurance coverages may be sequenced for coordination of benefits submissions. The adjudication results information from each Adjudicator are forwarded to the next adjudicator to explain the outstanding amounts being claimed.

  Specific data about the billable act (what was performed such as clinical treatment procedures, practitioner identification, service location, etc.) are modeled separately and inserted into the appropriate message types created from this model. See the A_Billable CMET for the specific types of billable acts that can be inserted into the generic Invoice structure. Healthcare products and their packaging type and quantity are included through the Product participation against the InvoiceElement Group or Detail.

  The Invoice may optionally reference a contract under which the billing is done (FinancialContract), accident information (incident type and date) are in the Accident act. Accident location and nature of injuries are included in the billable act. Attachments (HealthDocumentAttachment) containing any form of supporting information.

• Adjudication Results:

  The adjudicator responds to a PaymentRequest with a PaymentIntent (I will pay) that includes a set of AdjudicationResults explaining how the adjudicator has adjudicated each InvoiceElementGroup and InvoiceElementDetail on the invoice (e.g. pay as submitted, pay as adjusted, reject, provide information) and links to the AdjudicationResultsReason and AdjudicationResultsInformation observations to explain and inform about the results returned. A portion of these results is placed in the A_InvoiceCoordination CMET to be passed on to the next adjudicator in coordinate of benefits invoicing.

  Changes to Payor, Payee and insurance information are also returned with the adjudication responses.

  An AdjudicationResult may also reference related adjudication observations such as drug utilization reporting (DUR) information for drug interactions. This is specified using the A_AdjudicationObservation CMET; the CMET allows for multiple types adjudication observations to be included in an adjudication response to a Provider.

  A reference to a AdjudicationResultRequiredAct to be performed by the provider organization, may also be made. This could be a requirement to print an Explanation of Benefits (EOB) to be supplied to the patient/covered party. Associated with this may be the specification of a print form to be used. This is done by using the FormRole and Form classes.

• Payment Advice:

  Once an invoice has been submitted (PaymentRequest) and adjudicator has adjudicated and determined that they will pay for the invoice (PaymentIntent), the Payment Advice message is used to indicate payment (Payment). It is the Financial Transaction in EVN (event) mood. This class references the PaymentIntents that have been previously communicated to a Provider with the Invoice Adjudication Results. The Payment Advice also may provide Payee bank account data and may also list ancillary charges and credits against a Payee such as professional fees and lump sum adjustments to an account.

  The Payment Advice has two types: Summary and Detail. The detail message includes references to the adjudication results groups being paid and the invoice groups that they are the adjudicated result of.

  The Payment Advice Detail (Payment Advice Query Results) can be obtained by the (Payment Advice Query Request) based on the Payment Advice Summary received.

• Statements of Financial Activity (SOFA):

  Statements of Financial Activity may be requested and supplied as AdjudResultsGroups for a SOFA Payment. The results may also include summaries of all accepted, rejected/refused and/or reversed Invoices for a specified reporting period in the AdjudResultsGroupSummaryData. A SOFA Details request will obtain a result that lists specific AdjudicatedInvoiceElementGroups and the InvoiceElementGroup as per a set of query parameters. These are usually provided to help reconcile totals between Providers and Adjudicators.