CHAPTER 1 “Cashless Claims Workflow”

Step 1: Claim Sources

Initial Final Request

(PRE-AUTH)

After submitting all initial bills are made after discharge only after
docs available at that time Submitting all mandatory documents

Pre authorization assessment Pre authorization Pending assessment done

Done (either approved or denied)

If approved

Now all communication will be done between

hospital and insurance company
Approve Decline

Initial approval decline & cashless approved awaiting invoice

letter sent closed

Enhancement Final Request approved > 48hr approved <48hr

Enhancement approved
(multiple enhancement request Customer SNP PA final invoice review
Can come & may or may till when invoice is pending review again by accessors
not be approved).
 Final invoice tax review Approve & Pay
(whole new screen)

Bot Payment
Four stages

Cashless approved payment

Pending because of staggered no. of days

1. approved 2. reject

Paid & Closed

3. It Error 4. Cashless approved
payment pending

After (approved) stage

Paid & Closed Closed awaiting UTR

Step 1: Claim Source

The cashless claim journey begins at the point when a claim is initiated from a hospital portal
by hospitals / TPA. There are two key stages involved:

A. Initial (Pre-Authorization) Request

B. Final Request (Post-treatment documentation)

I. Initial (PRE-AUTH) Request

A. Document Submission:
The hospital submits all available initial bills and supporting documents for the patient.

B. Pre-Authorization Assessment:
The insurer performs a pre-authorization check based on submitted details.

If Approved:

An initial approval letter is issued.

The hospital may raise enhancement requests for additional approvals if the treatment cost
increases.

Each enhancement request is separately reviewed and may or may not be approved.

This loop can repeat multiple times.

Once treatment concludes, the hospital raises a Final Request.

If Declined:

The case is marked as declined and closed at the pre-auth stage.

II. Final Request (Post-Treatment Submission)

A. Submission Timing:
The final request can only be made after patient discharge and once all mandatory documents
are available.

B. Pending Assessment:
A final pre-authorization assessment is conducted again:

If Approved:

The insurer now engages directly with the hospital for all further communication.

The final invoice is marked as "cashless approved – awaiting invoice".

Depending on time:

If the final request is approved after 48 hours, the case is marked as Customer SNP till
invoice is received.
 If approved within 48 hours, a final invoice review is conducted again by the accessor.

III. Final Invoice Tax Review & Assessment

This stage involves a detailed tax review and is treated as a new evaluation screen. There are
four possible outcomes of this assessment:

 Approved

 Reject

 IT Error

 Cashless Approved – Payment Pending

IV. Post-Assessment Closure

 After final assessment and approval:

 If everything is correct and payment is processed:

 The case is marked Paid & Closed.

 If UTR (Unique Transaction Reference) is awaited:

 The case is marked Closed – Awaiting UTR.

Additional Notes:

 If Bot Payment is used, the system directly Approves & Pays the amount.

 In cases with staggered number of days, the payment may be pending until all benefit
days are accounted for.

CHAPTER 2 “Re-Imbursement Claims Workflow”

 Description of the PREVIOUS workflow between DD (Digit Desk)
and DC (Digit Care) for claim creation

[POV: A fresh ticket is assigned and to register claim you are working on digit desk
after reimbursement claim Intimation ]

STEP 1: Claim Intimation via Email

The claimant initiates the reimbursement claim by sending an email

to [Link]@[Link]

The email must include:

 Hospital name and pincode

 Patient name
 Date of Admission (DOA)
 UHID or ID card number

STEP 2: Auto-Response from Digit

Digit replies with a generic acknowledgment email that:

 Provides a ticket/issue number (e.g., HC-0001)

 Lists all mandatory documents required for claim processing:
 From hospital: HFB (Hospital Final Bill), DS (Discharge Summary), DB (Discharge
Bill), MB (Medical Bill), test reports, pharmacy bills, original receipts, SOE
(Summary of Expenses).
 From insured: Claim form (CC), KYC documents.

STEP 3: Update Ticket on Digit Desk (DD)

On the Digit Desk platform, you must:

 Update basic ticket details: type, priority, status, timestamps, issue description, product,
process, sub-process, reason, and policy number.
 Set the status:
 Pending with Customer if documents are incomplete
 Auto Classification in Process if all documents are received

Once updated, initiate a call for claim intimation and push documents to Digit Care (DC).

Digit Care (DC) – Claim Registration Process

STEP 4: Access FNOL Dashboard

In the New Health FNOL Dashboard, enter the policy number to view:
 Intimation ID (SF-ID)
 First intimation date
 DD ticket number
 Claim type and reason
 Classification status (must show Auto Classification Completed)
  If classification is complete, proceed to create FNOL (First Notice of Loss).

STEP 5: Fill Mandatory Fields

After FNOL creation, a form opens. Fill in:

a) Policyholder name
b) Policy name
c) Patient name
d) Mobile number
e) Email ID
f) Claim class type
g) Coverage
h) Loss cause
i) Claim type

STEP 6: Document Verification

Verify and validate the following documents:

 Discharge Summary (DS): Must include DOA, DOD, diagnosis, patient and doctor
names, discharge advice, and hospital details (add hospital if not listed)

 Hospital Final Bill (HFB): Must include entity name, bill number, date, and amount

 KYC: Must include document number and name

Each document tag (DS, MB, DB, etc.) has an IR (Information Required) option with a
comment box for missing or unclear data.

STEP 7: Register the Claim

After verifying all documents and filling all fields:

 Click Register Claim
 A pop-up prompts you to re-check: DOA, DOD, Patient Name, and Loss Cause
 If any required data is missing, the system prompts to Generate IR and send a customized
email for pending documents
 If all is complete, proceed and receive a Claim Number confirming successful
registration

X
Claim has been Created Successfully
Claim Number: 00000000000
OK

 This all flow is generic with minor tailoring is of V1, V2, V3 systems,
but recent version (V4) of system based on Claim Automation

CHAPTER 3: Claim Automation Process

 (Description of the CURRENT workflow Claim Automation for claim
creation)

HC ticket generated - (DD Ticket)

DD “ FNOL Automation”
(ticket)
(internally)
AI (ARIA)
Response Submit documents (s-doc) {AI service call - KVP classificatn.}

(backend)

Table Structure (docs) KVP extracted

(once ALL mandatory docs are extracted) BE LOGIC

[3 SCENARIOS]

All Mandatory docs & When only policy No. When nothing is
fields are available. is available. available.

(After This) -:

THE CLAIM STATUS:

[In DD]

If all mandatory docs and fields are available = In DD new status will show = PENDING FOR DD

1. AI RESPONSE FAILED CLAIM INTIMATION CLAIM CREATED

(Admissibility docs received)

which means everything has means SF-ID is created & in DC means in DC claim dashboard
to be done manually in DC Auto-Classification Completed status- Admis./Sub- Doc Received

* meaning aria analyses the mail that is it for claim intimation or not. If it is then only aria will
response.
 Claim Automation Process

The claim automation process begins when a Health Claim (HC) ticket is generated on the
Digit Desk (DD) platform. This is referred to as the DD ticket, and it triggers the First
Notification of Loss (FNOL) Automation process internally.

Once the ticket is initiated, relevant documents are submitted, termed as S-docs. These
documents are then passed to an AI system (ARIA) for classification and key value pair
(KVP) extraction. ARIA performs backend processing where the documents are parsed and
structured in a tabular format. If successful, all mandatory fields and documents are extracted,
which allows the process to proceed to BE LOGIC, where business rules are applied for
further decision-making.

At this stage, there are three possible scenarios:

 All mandatory documents and fields are available – The automation continues
seamlessly.

 Only the policy number is available – Partial automation may proceed based on available
data.

 Nothing is available – Manual intervention is required, and the process is halted until
data is provided

1. Post-Extraction Processing

If all mandatory documents and fields are available, the status in the DD system updates to
“Pending for DD”, indicating readiness for downstream processing. From here, three further
outcomes are possible based on system evaluation:

i. AI Response Failed: In this scenario, ARIA is unable to classify or extract the required
details, and hence the process must be handled manually within the DC (Digit Claims)
team. No automation proceeds beyond this point.

HC tickets which are currently pending for AI response and is present s_document is
considered as in this status.

If AI failed to extract the data - the ticket will be stuck into - OPEN Status in AI master_table.

When call back service failed to same the extracted status.

[RETRY] Mechanism: It tries again to either: Extract the missing data, or Save the data that
couldn’t be saved earlier

[Scheduler]: the tickets which are in Pending For DD - AI Response will be changed to “AI
response failed”. - Scheduler Checks for Stuck Claims, there’s a scheduler (like a digital
supervisor) that regularly checks for claims that are still waiting.

If a claim is stuck in a status called “Pending for DD” for too long, the system updates it to
say “AI response failed”—basically marking it as something that needs human attention.
ii. Claim Intimation: If the AI successfully identifies and classifies documents, an SF-ID is
created, and in the DC system, the status reflects “Auto-classification completed”. This
confirms that the claim has been successfully intimated using automation.

In this particular status , Sf-id is created for the particular ticket. Mandatory Field is “Policy
number” from ECARD or Email content. Following are the conditions to restrict for SFID
creation and will charge status to AI Response Failed. Hence not creating “Short FNOL ID”:

 If the multiple patient names(more than one) found in Discharge Summary.

 If the multiple DOA found in Discharge Summary.
 If the SFID is already present for the same policy number.

 DOA & DOD are same and status of ticket is “Pending for DD-AI Response” or “AI
response failed”: Claim can be registered.
 DOA & DOD are same and not mentioned status :Claim not need to register.
 If Policy number is master Policy.
 If Claim Number is present in Subject Line.

iii. Claim Created: If admissibility documents are successfully received and validated, the
DC system updates the claim dashboard status to “Admissibility/Sub-doc received”,
indicating that the backend process can now advance to the next stages of assessment.

If only following mandatory fields and documents are available, if not found claim should not
be created.

 DS, Discharge card, HFB, KYC, CC - Mandatory Fields.

 MB, PB, CP, DR - Optional Docs.

A) the KVP’s are maintained in document.t_lookup for particular document category.

B) DOA and DOD logic to check in DS and then in other docs.
C) For Loss Cause and Loss Type , the present logic is as follows:

 Auto Learning is done for the same == not in production.

If the given keys are present then , Claim Intimation (SFID Creation) process flows.

Claim has been Created Successfully

Claim Number: 00000000000

# Hence, CLAIM CREATED

 2. Now we will go on V4 screen

(We will see a ‘dashboard screen’ which is divided into three parts)

1. Today’s Cases

This section gives you a quick overview of the current workload. It has two parts:

a) Donut Chart: Each slice shows a type of case and how many are in that category. For
example:
 3 cases are waiting for KVP’s review.
 1 case is waiting to be assigned to V4.
 2 cases are waiting for classification.

b) AI Pipeline: This is like a smart assistant that reads the data and tells you the exact
numbers behind the pie chart. It helps you understand how many cases are in each stage
without guessing.

2. Health Claims Pipeline

This part works automatically. It connects directly to the database and pulls in health claim
cases based on certain rules. You don’t have to do anything manually—it updates itself and
shows the latest information on the V4 dashboard.

3. Admissibility V4

This is your “manual mode.” If you want to take control and pick a case yourself, you can do
it here. It’s like choosing a task from a list instead of waiting for one to be assigned to you.

4. Failure/Error Pipeline

This section is like a notice board for problems. If there’s a system error or something goes
wrong, it shows up here. It helps users stay informed about any issues that need attention or
fixing.

3. Data Verification Screen

After you’ve seen the dashboard, the next screen you’ll go to is the Data Verification Screen.
This is where the real checking happens -

The AI has already looked at all the documents and tried to figure out what type each one is.

For example:
If it sees a Discharge Summary, it will tag it under the D.S. (Discharge Summary) category.
If it sees a Lab Report, it will tag it under the Lab Reports category.
So, the AI has already sorted everything into folders, like a super-fast assistant.

What do you need to do?

Your job is to double-check the AI’s work. You don’t have to start from scratch. Just look at
each document and ask:
“Is this document really what the AI says it is?”
“Is this Discharge Summary actually a Discharge Summary?”
It’s like proofreading—just making sure everything is in the right place.

Accuracy Percentage

To make the job easy, the AI also shows you an accuracy percentage. This tells you how
confident it is about the tag. For example:

If it says 95%, it’s very sure the document is correctly tagged.

If it says 60%, you might want to take a closer look.

#Extra Insight: Tagging vs. Sorting

 Tagging: The Identity Check

In document terms, it means identifying what each file is: Medical Bill, Discharge
Summary, Lab Report, and so on. It’s the “What am I?” step.
Purpose: Helps the system and users recognize the document type at a glance.

 Sorting: The Shelf Placement

Once tagged, sorting is like arranging the tagged documents in a particular order,
usually grouped chronologically.

4. De-duplication Screen

Understanding the Document De-duplication Feature

At the top left corner of the screen, there is a section labeled “D-Duplication.” This feature
helps identify duplicate documents within a specific category, using AI.

For example, if you see “1/13 Discharge Summary,” it means there are 13 discharge summary
documents in total, and the system has flagged 1 of them as a possible duplicate. This helps
reduce errors and avoid reviewing the same document more than once.

Next to this, you’ll see a percentage with a reversible arrow symbol (for example, 80% ⇌).
This shows how similar the two documents are. In this case, the system believes the two
documents are 80% alike, which suggests they might be duplicates.

As an assessor, you have a few options:

 You can mark the document as a duplicate if you agree with the system.
 You can undo the action if you think the documents are not actually duplicates.
 You can move on to the next document in the same category (e.g., the remaining 12
discharge summaries).
 Once all documents in that category are reviewed, by clicking on the system will
automatically take you to the next category, such as Medical Bills (MB) or Hospital
Final Bills (HFB).
This feature saves time, improves accuracy, and ensures that only unique and relevant
documents are reviewed during the claim assessment process.
 5. Data Entry Screen

After document classification, the next step in the workflow is the Data Entry screen. This
screen is designed to allow assessors to review and, if needed, edit the information extracted
from documents.

At the bottom of the screen, you’ll find two navigation buttons:

Previous – to go back to the last document category.

Proceed – to move forward to the next document category (e.g., from Hospital Final
Bill to KYC).

Between these buttons, there is a data entry section that displays fields relevant to the current
document being reviewed. These fields are automatically filled using AI-powered such as
Google OCR. However, all fields remain editable, allowing assessors to make corrections if
needed.

Examples:

 For a Hospital Final Bill (HFB), the fields may include:

 Entity Name (type of document)

 Bill Number
 Bill Date
 Page Number

 For a KYC Document, the fields are simpler:

 Entity Name
 ID Number
 Page Number

Common Fields: Some fields, such as Entity Name and Page Number, are common across all
document types.

Mandatory Fields: Fields that are required for submission are marked with an asterisk (*),
indicating their importance and ensuring they are not left blank.
This structured layout ensures that data is captured accurately while giving assessors the
flexibility to make adjustments when necessary.

6. Data Sorting Screen

The Data Sorting screen is designed to help users organize documents in a desired order—
typically in a chronological or logical sequence. This step ensures that all documents are
grouped and arranged correctly before moving on to the next stage of processing.
On this screen, you’ll see three folder icons, each serving a specific purpose:

i. Current Document Folder (e.g., E-Card)

This folder displays the name of the document category currently being sorted. All
documents tagged under this category will appear here for review and arrangement.
ii. Individual Bills Folder
This is a fixed folder that automatically collects all entered bills related to the current
document type. It helps in grouping similar bills together for easy access and
verification.

iii. New Bill Folder

This folder acts as a safety net. If a document was incorrectly tagged under the current
category (for example, a non-E-Card document mistakenly placed under E-Card), it can
be moved here. This ensures that misclassified documents are not lost and can be
reassigned correctly.

Once sorting is completed for the current category, the system will automatically move to the
next document category, streamlining the workflow and reducing manual navigation.
This structured sorting process improves accuracy, reduces errors, and ensures that all
documents are in the right place before assessment.

Now for further process we will automatically re-directed to V2 assessment health screen L4
Bill Entry for bill entry -

7. Bill Entry Process (V4 system)

The V4 Bill Entry system is designed to streamline and automate the process of entering and
verifying bills, while still allowing manual edits when necessary. Below is a step-by-step
explanation of how the process works:

1. Bill Entry Table Setup

Each bill entry (e.g., for HFB or MB) may contain multiple individual bills. For example:
HFB may have 2 bills
MB may also have 2 bills
Each of these bills must be entered into the system individually.

2. Basic Details (Mandatory Fields)

For every bill, the following basic details must be filled in:
 Entity Name
 Bill Number
 Bill Date
 Patient Full Name
 Total Bill Amount
If any of these fields are not applicable for a particular bill, the user can mark them as “BE
NA” (Bill Entry Not Applicable) using a checkbox.

3. AI-Generated Tables
The system uses Google OCR to automatically extract data from uploaded bills and generate
one or more AI-generated tables. These tables contain headers and values based on what the
AI could read from the bill.
Users can:
Proceed with the AI-generated table as-is, or
Create a new custom table by mapping the bill’s headers to predefined Digit Columns, which
include:
 Description
 Quantity
 Per Day Charge
 Discount Amount
 SAC (Service Accounting Code)

4. Finalizing the Bill Table

Once the table is ready (either AI-generated or user-created), the user must:
Fill in all required fields
Select an Expense Category (this is mandatory)
Map other relevant fields as needed

5. Verification and Submission

After completing the bill entry:
Click ‘VERIFY’ to confirm that all data is accurate.
Once verification is successful, click ‘SAVE & CONTINUE’ to proceed to the next step in
the workflow.