Testing

Testing only…

  1. RightFax or Mail Room
    a. Right Fax is being Replaced by Xmedius
  2. Anydoc (The document always resides in here).
  3. Image Processing -> Push into Workdistribution (Inhouse Application -> Queue of available cases to be processed)
  4. Workdistribution is outside of Insupport CRM and used primarily to assign individual cases to individual users
  5. NOte: The physical image still resides in Anydoc only (unlike AWS like in SFDC).
  6. Once an agent is assigned with a new document in workdistribution, he/she will open Insupport CRM separately to search for the patient in the database and if not found , then they will start brand new application process in Insupport and if patient is found then they will just copy the document ID number and paste into one of the fields of existing application.
  7. Note : Risk of losing the physical document if it is deleted from anydoc even thought the reference Id will be in Insupport application.

—————————Tersera PAP / Varubi (RB/PAP)———————————————-INsupport
Pre-condition: In anydoc we received 3 documents – document 1: New PAP tersera 2. New PAP Varubi 3. New RB Varubi

New PAP Tersera:

  1. will open the document either through WD or Anydoc to get Patient PHI details and also it has Enrollment Form with prescription details and Patient consent / HCP consent
  2. Search for the patient FN / LN / Other factors in Insupport CRM
  3. No results found
  4. Create New Patient Profile in INsupport – Patient and Patient Address Tables
    (FN/LN/MN / DOB/G/ Mailing ADdress / City / State / Zip / SSN / Contact Phone / Email)
  5. Create Application – Application / Line Item (Prescription product) / App Product Requested (Which product is associated from actual master product table ) / Patient Eligibility PR Table (PAP informaiton like Income, HH, Size etc) / Practitioner Table / Practitioner Address Table / ref_Product (master product table that has all the products including varubi / tersera)
  6. Determine Outcome (Outcome Validations – Hard Coded)
    a. Ref_income table (Bridge table)
  7. If approved – Order is created and if not approved – Applicaiton is marked as “denied” or “Incomplete’ with reasons displayed. (Action to be taken by the user to fulfill these reasons to get it approved).
  8. Once order is created, with release date will be order created date, with status as “pending” and Order Fulfillment job runs and now the status of this order is “Fulfilled” (Patient Order table / Patient Order Line Item)
  9. The fulfillment file is sent to MV via SFTP through jobs
  10. MV processes the orders and they will send us back Shipment status details and shipping info via SFTP data feed (
  11. Insupport will consume and updates the details (Into the table Patient Shipping Delivery)

New RB Varubi:

  1. Steps 1 through 4 above are followed
  2. Step 5 will be also be completed but NO PAP information and adding new insurance details (patient_insurance table)
  3. Evaluate application process -> This will determine if I have enough details for BI
  4. Here we use “Case” table – (master table that holds all the BI / BV details – which in turn has multiple sub-tables)
  5. Case page details – record of the application, they start the processing of BV (case_lineitem and case_lineitemstatus tables)
  6. All the details are inserted in case page – BV completion based on Emdeon search or remyhealth (current)
  7. Different prior authorizaitons like (step therapy or PA or Copay) -> Drug is covered
  8. Notify Patient or HCP -> that ends

Determine Outcome Process:

  1. ref_incomematrix table : This consists of different product groups and their HH size based income (FPL table)
  2. ref_validation reasons: This consists of differnt validation reasons based on each program (can contain multiple ndc of the same product / or different products)
  3. Determin outcome logic:
    a. Seeks for the information from ref_incomematrix for income details and compares with patients entered income details (PAP information)
    b. seeks info for any incomplete reasons from ref_validations table for each program
    c. based on a and b it will be either approved or denied or incomplete Adding new Products to the existing program:
  4. No impact if the new products are part of the existing group for PAP
  5. No imact if the new products are part of the existing group for RB (need functionality and regression testing)
  6. Impact of cloning the existing program to a new program if the new product doesn’t belong to the any of the existing programs (this will take time and need more testing)
  7. New product but doesn’t belong to existing program group (for tersera) then we might have to create new product group (all together new) – ref_incomematrix / master product table (ref_product) / ref_validation reasons to be created (only if it’s new program)

Testomg

Testomg

Scroll to Top