Manage orders
Track order status, patient context, selected tests, payments, sample progress, notes, and report readiness.
What the Orders page shows
The Orders page is the main list for finding and opening clinical orders in the Lab Panel. Use it when a patient calls with an order number, when reception wants to check payment state, when a technician needs the linked samples, or when a manager wants to review progress across active work.
The list is scoped to the current branch. It includes standard orders for the branch and routed sample orders that the branch is allowed to process.
Tabs
The page groups orders into practical tabs:
| Tab | What appears there |
|---|---|
| Ongoing Tests | Active standard orders in pending, dispatched, sample processing, partial results, ready results, or waiting release states. |
| Routed Samples | Orders or samples routed to the current branch from another branch. |
| Finished Tests (Successful) | Standard orders whose workflow is complete. |
| Canceled Tests | Orders that were cancelled and should not receive more work. |
Ongoing Tests and Routed Samples show branch-scoped count badges. Finished Tests and Canceled Tests intentionally do not show counts, keeping completed historical volume from competing with active work.
Use the tab before searching. For example, if a completed order is not in Ongoing Tests, switch to Finished Tests before assuming it is missing.
The tabs use the saved order lifecycle bucket so the list stays responsive when the branch has many records. The status badge inside each row still calculates the operational state from samples, results, home visits, and release progress.
Order row information
Each row is a compact four-part summary: order code and created time; patient and demographics; one operational-status badge with a short test list and visit type; and the total with one payment-status badge. The list shows up to two test names, followed by +N when more tests are attached. Hover the operational status to see result-entry and release progress without adding another status label to the row.
In Routed Samples, the tab already supplies the routed context, so rows do not repeat a Routed badge. The final part instead shows only the sample codes, sample count, and test count assigned to the current branch.
Use the search box to find orders by the public ORD code shown in the row or by patient name. The internal UUID is not intended for day-to-day lookup.
The operational status is calculated from order, sample, and result state. It is not just a simple text field. When the status says results waiting release, for example, it means the work has moved past basic intake and sample processing and now needs clinical review or release.
The single payment badge uses the finance labels Paid, Unpaid, Partially Paid, and Failed Payment. It is a quick triage label based on the saved payment state and the paid-versus-total balance. Open Payment when you need the exact ledger, refund, receipt, or payment-request history.
Filters
Use the status filter to narrow by workflow state. Use the payment filter to separate Paid, Unpaid, Partially Paid, and Failed Payment orders. Use Created Today when reception or operations needs a same-day view.
Filtering does not change the order; it only changes the visible list. If a record disappears after filtering, clear the filter before reporting it as missing.
Saving and resuming intake drafts
During order creation, use the top Save Draft action whenever intake may be interrupted. The compact create page also autosaves changed fields every 30 seconds. Drafts store the selected patient, patient history, reason for tests, tests and packages, requirement confirmations, visit details, referral, contract, and notes without creating a clinical order, sample label, invoice, or payment request.
Use the top Resume Draft action to reopen one of your own drafts from another signed-in session. Drafts belong to one user and branch, expire after 30 days, and cannot be opened by another user or branch. Saving from a stale browser tab is blocked; reload the latest draft rather than overwriting another session.
Submitting a resumed draft claims it for conversion and creates exactly one order. A second submit cannot create a duplicate. Use Discard Draft when the intake should not continue; discarding does not create or cancel an order.
Row actions
Select the row itself to open the order overview. Use its compact Actions menu to open a more specific operational area:
- View Order opens the order overview, patient summary, price boxes, activity, and shortcuts.
- View Samples opens the Sample Log for the order.
- View Results opens the review worksheet when the user has permission.
- Open Payment opens the order payment ledger for standard orders when finance permissions allow it.
Use the most specific action. For barcode or rejection work, open samples. For result approval, open results. For payment, open the payment page. Manual WhatsApp communication starts from the order header so the employee can confirm the saved recipient and choose the appropriate message template.
The order view header
The order view page summarizes the active order at the top. Its title is the public order code without an extra "Order" prefix, and the copy icon beside it copies that code for messages, calls, and handoffs. The header also shows operational status, patient name, patient identity details, visit type, routed-order marker when relevant, payment badge, paid amount, due amount, and total amount.
Use Print Barcodes beside the Actions menu to open one print job containing every current sample label for the order. The button is unavailable until the order has at least one sample. Confirm the patient and sample codes before attaching each printed label.
Use Print Worksheet beside it to print the internal laboratory worksheet. It contains the patient identity captured at order creation, order context, medical history and notes, every sample with its barcode and current handling state, and every ordered test with its linked sample. The blank result, technician-note, initials, and signature areas are for bench operations only; this worksheet is not a released patient report and does not replace result entry or approval in Kashef.
Use Send WhatsApp beside the print actions to choose an active Arabic message template. Kashef uses the phone and patient identity captured on the order, fills the order number and any available result-link or loyalty variables, then opens wa.me or WhatsApp Web in a new tab. Review the recipient and message there; Kashef never presses Send and does not send this message through an API.
If the button reports a missing or invalid phone, do not use the prepared link. Order identity snapshots stay fixed, so changing the patient profile does not replace the recipient captured on an existing order; follow your laboratory's approved contact-correction procedure. Use an international number with its country code when registering future orders. A results-link template remains unavailable until a result is released and the patient portal can create a secure link. A loyalty template remains unavailable until loyalty is enabled and the order's earned points are posted. Laboratory administrators manage template names, Arabic content, activation, and order under Admin → WhatsApp Templates. Templates accept only the documented variables shown on that page; unsupported variables cannot be saved.
Open Actions for samples, the results sheet, payment, or another authorized operation. The same menu pattern is used on Order Details and Order Payments; exception actions are separated from routine actions so cancellation or correction is harder to trigger accidentally.
Use View Full Details in Order Summary when you need the complete captured order: patient identity, tests and packages, original and final pricing, applied discounts, contract or insurance context, price list, clinical reason, and notes.
Keyboard users can press Tab once after a page opens to reveal Skip to main content, then press Enter to move directly past the global toolbar and navigation. This places focus at the operational content so the order heading and primary actions can be reached without traversing the full application chrome on every order.
If a user has patient permissions, the patient name links to the patient profile. This is useful for checking history, phone number, previous results, or profile corrections.
Patient history and reason for tests
The Patient History section appears after Order Information in the compact create workspace. Review the conditions already saved on the profile, select or clear conditions as needed, and keep the free-text history note current. Submitting the order updates the patient profile so the same information is preselected on future orders. The order also keeps a snapshot of the selected history, so later profile changes do not rewrite the clinical context of an older order.
Use Reason for Tests for the symptoms, follow-up, screening purpose, or clinical question behind this specific order. Do not duplicate general handling instructions there; keep those in Order Notes. The reason is visible on Order Details, the full summary, each sample's details, Result Entry, and Result Review so collection and clinical staff share the same context.
The lifecycle checklist uses the same semantic colors as the rest of the Lab Panel in both light and dark mode: green for complete work, amber for the current or overridden step, red for blockers, and the neutral panel surface for pending work. Dates in the checklist appear as relative Last Update values. Hover the dotted-underlined time to see the exact timestamp.
The SLA Deadline card shows one concise timer: Due in ... while time remains or Late by ... after the deadline. The whole card is green when on track, amber when at risk, and red when overdue; there is no separate On Track badge.
Authorized users can use the edit icons on Ordered By, SLA Deadline, and Priority to correct the ordering physician, set a manual order SLA deadline, or change order priority without leaving the order view. Leave the SLA field blank to return to the calculated deadline from samples and ordered tests.
The checklist header shows progress only. It does not repeat the next step and its relative date; the highlighted step in the checklist body is the source of truth for what needs attention next.
The Creating Order step identifies the record with the public display code shown throughout the Lab Panel, not the internal UUID.
The summary panel counts Total Tests as ordered tests and Packages as distinct selected packages, so a package containing several tests is counted once as a package. Package tests in Required Tests show the package name beside the test.
Required Tests shows the first four rows by default. Use Show More when you need the full list. In Kashef Cloud, Order Activity also shows the first four operation summaries and View details opens the complete audit payload. Local Kashef does not render the activity feed; use View Order Activities in Kashef Cloud to open the same order and review its audit trail there.
The payment badge always includes its context, such as Payment: Paid, Payment: Unpaid, Payment: Partially Paid, or Payment: Failed Payment, so the state cannot be confused with the operational order status.
Payment page and refund requests
Use Payment in the Order View header to open the order's financial ledger. The payment page uses the same order header and breadcrumbs as Order View so staff can confirm the patient, order, SLA, and balance before taking finance action. The table combines payments, posted refunds, pending refund requests, and their finance references in chronological order. Use the receipt action on a completed payment or posted refund to open its printable receipt in a new tab.
Use Print Invoice to open the same printable invoice used by the Invoices resource and the Payments resource. Use Payment Request when the full outstanding balance must be sent to Cashier Workbench, including field collection or a replacement payment after a refund. The action always uses the current full due amount and prevents duplicate pending requests.
Creating an order automatically creates one full-due payment request with a PQR display code. The manual Payment Request action uses the same service for later cases, such as a replacement request after a refund, and remains hidden while another request is pending. Cashiers resolve requests through the existing order row and Collect Payment modal, including the same single-payment, split-payment, finance-account, POS-machine, and receipt options. Partial collection keeps the request pending; collection of the full requested balance completes it.
The Settling Payment result in the Order Lifecycle Checklist shows the latest payment request code and current request status together with paid and due amounts. This keeps the order checklist, payment ledger, cashier queue, and activity trail aligned around the same request.
Managers have Create Custom Discount by default. The dedicated permission Order Discounts: Create Custom can also be granted to another role or individual user from access control. Choose an amount or percentage, review the new total, and enter a required reason. Kashef records the requester, reason, original total, discount, and resulting total with a DSC audit code.
Applying the discount immediately updates the order and invoice totals. If a payment request is still pending, Kashef cancels it and creates a new request for the discounted due balance. If the discount makes the order overpaid, Kashef creates a pending refund request for the excess amount and reserves the refundable payment balance for Cashier Workbench. The discount audit code and reason stay internal; the patient invoice shows only the discount amount.
Use Request Refund when money must be returned. The Order Payment page and the Payments resource use the same refund modal and validation. Choose a full or partial refund, select every original payment transaction involved, enter the partial amount when needed, and provide a reason. When you start from one payment in the Payments resource, that payment is selected first, but you can still review the same transaction list for that order.
Submitting the modal does not move money or reduce the paid balance. It creates a pending request for Cashier Workbench. The cashier verifies the original payment split, chooses the real payout method and finance account, and then posts the refund. Pending requests reserve their requested balance so another request cannot claim the same amount.
The order header, order summary, payment page, invoices, receipts, payment requests, cashier workbench, and finance reports use the same finance summary. If a payment is refunded and the order is collected again through a payment request, the paid amount is the net collected balance after posted refunds and the due amount returns to zero when the replacement collection covers the full order total.
Amending tests before collection
Use Amend Tests when reception selected the wrong test or package and no sample has been collected, received, routed, processed, or resulted. Add or remove the required tests, review the updated order summary, enter a specific amendment reason, and apply the change. If the action is disabled, hover or focus it to see which lifecycle boundary prevents the amendment.
Applying an amendment keeps the old uncollected sample labels as rejected historical records and creates a fresh sample plan with new labels. Kashef recalculates catalog pricing and the existing order discount, updates the outstanding payment request and invoice, and creates a pending refund request when the corrected total is below money already collected. Do not reuse a superseded label.
Every amendment has a sequential version. Kashef retains the operator, reason, tests and totals before and after, superseded labels, replacement labels, and timestamp in the audit trail. If another user changes the order while the amendment screen is open, reload the order and review the latest version before trying again.
Cancelling an order
Users with update permission may see Cancel Order. Enter a specific cancellation reason before confirming. Kashef retains the reason, operator, and time in the clinical and finance audit trail. Cancelling marks the order as cancelled and makes its order, sample, result, and payment workflows read-only. Use it only when the order should stop operationally. Do not cancel an order just to correct a test, payment, or sample mistake. Correct the specific issue when possible.
Cancellation removes the order from Cashier Workbench immediately. Pending payment requests are cancelled, in-flight pending payment attempts are marked failed, and an unpaid issued invoice is voided in the same operation. If money was already collected, Kashef creates a pending full refund request for the refundable payment balance; the cashier must still verify and post the actual payout. Do not return money outside that tracked refund workflow.
Before cancelling, check whether samples were collected or results were released. Cancelled result pages remain available for traceability but hide entry, approval, rejection, release, print, and delivery controls. Cancellation preserves the historical record; it is not a delete action and does not erase previously released clinical evidence.
Secure order attachments
The order view accepts PDF, JPEG, PNG, and WebP files up to 10 MB. Before upload, remove unrelated patient information, credentials, keys, tokens, and private material. Kashef detects the real file type and signature, generates the storage name, calculates a SHA-256 hash, stores the object privately, and keeps it quarantined until the safety scan passes. Pending, unsafe, failed, and legacy-unscanned files cannot be downloaded.
Each attachment shows its detected type, size, scan state, uploader, upload time, and retention review date. A clean file is served only through an authenticated, same-laboratory order authorization check with private no-store response headers. The default retention review is seven years after upload; follow the laboratory's approved retention and legal policy when a different period is required. Upload and scan evidence remains in the audit log.
Activity and audit trail
In Kashef Cloud, the order view groups related audit events into one operation summary. An Order Created entry can contain the order, samples, payment request, invoice, notifications, and field changes created by the same action. Select View details to open the complete grouped timeline. In Local Kashef, select View Order Activities in Kashef Cloud to open the same order's activity history. Activity history is especially important for cancelled orders, requirement overrides, rejected samples, finance changes, and result corrections.
Every note added from the order view records the authenticated staff member and exact time. A multiline note remains one attributed entry. Older imported free-text notes may show Legacy note — author unavailable when no reliable original actor exists; do not treat that label as a current authenticated author.
Handoff guidance
Reception should use Orders to confirm patient and test setup. Cashier should use the payment link or cashier workbench for money. Collectors and technicians should move into Samples. Reviewers should move into Results. Managers should use the order view when they need the full context before approving an exception.
When training new staff, teach them not to solve every problem from the Orders list. The list tells them where to go next; the dedicated page contains the action that keeps the audit trail correct.