[RFC] sale_medical_insurance: Insurance sales and adjudication

[lasley]

This module will allow for a medical.insurance.plan to be applied to a sale.order, using a select box similar to the way that Carrier Rates are currently selected.

A field will also be added to select the patient that the order is associated with, which would be domain restricted to any patient that is related or a child of the partner_id in the sale.

From a high level, there are two ways for an insurance transaction to take place:

• Insurance payment is made directly to the provider after services are rendered and bill submitted by provider
• Insurance reimburses patient after services are rendered and bill submitted by patient

In the event of a direct payment to the provider, a pre-authorization is required. In the US, we have two types of pre-auths:

• Prospective - This is typically used in clinical settings, to see what an insurance is willing to pay before the procedure is performed or medicine prescribed.
• Retrospective - This is the most common pre-auth, and is after a procedure is performed or drug is dispensed. It is to determine what the patient pays, and what the insurer pays.

As I see it, Prospective would be during quote stage & Retrospective would be at sale invoicing.

When the sale is invoiced, two invoices will be generated - one to the insurance company and one to the customer. The customer is then responsible for their portion, in a process similar to a down payment. The transaction would be completed in the books once the insurance portion is received.

In the event that a patient is being reimbursed, the clinic or pharmacy would be unaware of the insurance from a billing perspective. In that case, I believe it would go through the standard cash process from the viewpoint of the provider. The patient would then submit their bill of the full service to their insurance provider in the hopes of receiving money back.

cc @laslabs

[jcdrubay]

What is very important to track is:

• what does the insurance agree to pay for? It is very common that the insurance agrees for part, but not all.
• another big question is who needs to pay what: direct payment from insurance or reimbursement to the patient

I imagine this information needs to be stored at the sale order line level.

Then, in large medical centers in Vietnam, there is a dedicated department which connects with insurance to solve this questions (for each medical file). Then having a insurance_state on the sale order would help them track for which file they need to check. Yet this, might happen sometimes before the sale order is created; from the appointment time so insurance_state might be more meaningful directly on the medical services provided: medications, appointments and laboratory tests.

[lasley]

Sounds like we have very similar healthcare systems. In the first point of the payment pre-auth, we have two different sides of it in US:

• Prospective - This is typically used in clinical settings, to see what an insurance is willing to pay before the procedure is performed or medicine prescribed.
• Retrospective - This is the most common pre-auth, and is after a procedure is performed or drug is dispensed. It is to determine what the patient pays, and what gets sent to insurer.

As I see it, Prospective would be during quote stage & Retrospective would be at sale invoicing.

When the sale is invoiced, two invoices will be generated - one to the insurance company and one to the customer. The customer is then responsible for their portion, in a process similar to a down payment. The transaction would be completed in the books once the insurance portion is received.

In the event that a patient is being reimbursed, the clinic or pharmacy would be unaware of the insurance from a billing perspective. In that case, I believe it would go through the standard cash process from the viewpoint of the provider. The patient would then submit their bill of the full service to their insurance provider in the hopes of receiving money back.

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.