Tasks

Work ClaimPod does on its own. This page covers Tasks - what has run - and Schedules - what will run - because the question spans both: did my recurring import actually happen? A bulk action’s own page is an update batch, filed under Batches.

Who Can See It

Tasks is open to User and Administrator. Schedules is Administrator only.

Some task types need a particular role to start, by hand or with Run Now. Picking one in Create without that role shows the reason in place of the form, with no Create button, and Retry and Run Now are greyed with the same reason. A Superadmin passes every gate.

Task type	Needs	Reason shown
Export Claims, Export Statements	User	“Running a batch needs the User role.”
Generate Statements	User	“Generating statements needs the User role.”
Import Data	Administrator	“Running an import needs the Administrator role.”
Purge Audit Records	Administrator	“Purging audit records needs the Administrator role.”
Purge Import Data	Administrator	“Purging import data needs the Administrator role.”
Seal Audit Records	Administrator	“Sealing audit records needs the Administrator role.”

Tasks

The Tasks list: status tiles for Total, Pending, Processing, Completed and Failed above a table of completed tasks such as Export Statements, Import Data and Export Claims, each with its start, finish and duration

The tiles above the list count every task the client still keeps, not only the page on screen, and keep up as tasks run. Finished tasks are deleted over time by Purge Import Data (see Purging Import Data).

Tile	What it counts
Total	Every task still kept, Canceled ones included
Pending, Processing, Completed, Failed	The tasks in that status. Selecting one filters the list to it; selecting it again, or Clear, shows everything

The list is paged, newest first.

Column	What it shows
ID	The run
Task	What kind of work it was. An import names its mapping, such as “Import Data · Standard EDI 835”
Status	Pending, Processing, Completed, Failed or Canceled
Started, Finished	When
Duration	How long it took

A task never retries on its own. One that fails ends Failed with the reason in its results.

Failure	What the results say
A failure ClaimPod can explain, such as a refusal or a missing file, or a task that could not be queued or whose client is inactive	Its own sentence
Any other failure	“The task failed unexpectedly - the cause is in the server log.”
The worker stopped mid-run, in a crash or a restart	Within about a minute, “The worker stopped before the task finished.”; Retry then works on it
A statement cycle in which any account could not be billed	How many accounts could not be billed. Retry bills only the accounts still unbilled, never one twice
The instance is read-only	Nothing: queued tasks wait as Pending, and only a task already picked up ends Failed

Opening a task opens a panel from the right, titled with its number and name, such as “Task #12 - Import Data · Standard EDI 835”. It shows when the task was created, started and finished, and its parameters and results. A retry shows Retry Of with the task it re-ran, and the task it re-ran shows Retried As. A Bulk Action row you can open shows its update batch instead.

Schedules

Column	What it shows
Task	What it runs
Trigger	When, in plain words
Next Run	When it is due
Last Ran	When it last went, or Never Ran
Active	Whether it is running at all

The list has a search box and an Active / Paused filter.

Actions

Action	What it does	When it is offered
Create	Starts a task now, or adds a schedule	On Tasks, or on Schedules for an Administrator
Task Info	Opens the task	Every task, except a Bulk Action you can open, and selecting the row does the same
View Results	Opens its update batch	A Bulk Action task you started, or any for an Administrator, in place of Task Info
Retry	Runs the task again as a new task with the same parameters; the original keeps its record	A Failed or Canceled task, once per task, while the task is still kept. Not a batch run, which is retried from its batch page, an uploaded import, which is re-run from Import Batches, or a Bulk Action, which is retried from its results. Greyed when its type needs a role you lack
Cancel	Asks a running task to stop. It also ends a task stuck in Processing with no live worker, as Canceled	While the task is Processing, for tasks that can be canceled. Not a Bulk Action, which is canceled from its results
View History	Shows what changed on the task and when	Every task
Edit	Changes a schedule’s task, timetable or parameters	From a schedule’s row menu
Run Now	Runs a scheduled task once, immediately. The toast names the task, such as “Task #12 started.”	From a schedule’s row menu. Greyed when its type needs a role you lack
Delete	Removes a schedule	From a schedule’s row menu

Run Now does not change the timetable: the next scheduled run still happens when it was going to. Deactivating a schedule stops it without losing it, which is usually what you want over deleting.

A schedule fires once per slot. A new schedule waits for its first slot rather than running at once, and slots missed while ClaimPod was down fire once when it comes back, not once for each missed slot.

If someone else changed the schedule after you opened it, Edit is refused with a notice and Reload, which refills the form. Switching Active on or off is refused the same way, as a “Couldn’t update schedule” toast with Reload. See A Save Was Refused.

Export Claims and Export Statements cannot be scheduled: a batch run starts from its batch page. Neither can Bulk Action, which starts from the places listed under Update Batches. An older schedule for one shows a warning when you edit it, and should be deleted. If one still fires, it records a Failed task saying a batch run starts from its batch page, and the schedule is switched off.

Import Data

Import Data pulls files from a connection and reads them with a mapping. Its parameters:

Parameter	What it does
Import Mapping	The active mapping that reads the files
Connection	The connection to pull from
Files	Files picked from the connection, or wildcard patterns such as `*.edi`. Empty pulls everything
Move Processed Files	After a successful import, moves the pulled files into the connection’s `processed/` folder
Hold Ambiguous Patients for Review	A patient who only partly matches an existing one waits in Import Review instead of becoming a new record
Send Charges to Coding Review	Charges with a missing or unrecognised procedure or diagnosis code wait in Coding Review instead of going straight to billing

The Follow-up Sweeps

Two of the schedulable tasks fill work queues rather than moving data. Both take a Threshold (days) parameter - the age at which something becomes worth chasing. What the items look like is on The Queue Processor.

Sweep	What it raises	When its items close
Follow-up Claims	Submitted claims the payer still owes money on, or rejected. Each item carries its reason: Rejected, Denied, Partially paid, Remittance held or No response yet	Once the payer’s share is settled
Follow-up Visits	Visits that have gone unbilled, with why each one is stuck	Once the visit is billed

A claim whose only remaining balance is the patient’s is not chased: that money is collected with statements. An item Waiting until a date stays put rather than being raised twice, and the sweep that runs on or after that date brings it back.

Neither sweep runs until someone schedules it, so Follow-up Visits stays empty until then, which is a configuration choice rather than a fault. Follow-up Claims still gets a claim on the day a 277CA or 999 rejects it, with or without a schedule.

Purging Import Data

Purge Import Data is one of two scheduled tasks that delete. Like the sweeps, it does nothing until someone schedules it, and until then every upload is kept indefinitely.

It removes	Once it is older than
An import’s uploaded file	The uploaded-file window, 180 days by default
An import’s staged rows and original text	The staged-rows window, 1 year by default
Rule findings and rule firings	The staged-rows window, never less than 90 days
Findings on records that have been deleted	-
Finished tasks (Completed, Failed, Canceled)	The staged-rows window, never less than 90 days. It keeps the latest of each task type and each schedule, any task tied to an unfinished import or bulk run, and any task a kept task retried

An administrator changes both windows on the client’s Settings tab. The import run itself, its counts and its row errors are kept; what a purge leaves behind is on Import Batches. Test Run reports what a run would purge, rule history and tasks included, and deletes nothing, which makes it the safe first run on a new client.

Purging Audit Records

Purge Audit Records is the other. It does nothing until someone schedules it.

It deletes	Once it is older than
This client’s change history, PHI access and audit access records	The client’s Audit Log retention window on its Settings tab, never inside ten years
System change history, system audit access records and the record of sign-ins	Ten years

Its result names the retention window it used and how many records it removed from each log. Test Run counts what a run would delete and deletes nothing. The task cannot be canceled once it is running, so a test run is the safe way to see the numbers first.

Sealing Audit Records

Seal Audit Records starts on its own once a day for every client, within an hour after 01:30 UTC, so a new row appears in Tasks each day. It seals each finished day of every audit log and checks every sealed day against its seal: a record changed, removed or added afterwards fails the run, and the error names the log and the day. It cannot be canceled.

States

A suspended client’s schedules do not fire, and a task already queued for it fails with “The client is suspended, so the task did not run.” The export that offboarding starts is the one exception. Its schedules resume when it is unsuspended.
No tasks found. on an empty task list.
Never Ran on a schedule that has not fired yet.
No schedules yet. on an empty list.