Underwriting requirements tracking software keeps every open requirement on a life insurance case (the Part 2 interview, paramedical exam, blood and urine profile, attending physician statement, driving, prescription and MIB checks, inspection report and forms) with its supplier, its status and the date it should arrive, so the case manager sees what is late before the producer calls to ask. Most trackers stop at status, and a vendor status of "pending" is where the weeks hide. The test of the software is its dates: each one should come from that supplier's own recent turnaround, and a requirement that stops moving should be flagged within days, with a reason. In Botminds' New Business Case Management, a requirement tracker agent does exactly that for every open requirement, every hour, and the case manager decides what to do about the ones that stall.
The examples below come from a fictional sample carrier, Cedarbrook Life, and its fictional vendors and doctors' offices as they run through the solution. The rules and research are linked where they appear.
The same requirement, very different clocks: APS turnaround by doctor's office
What is underwriting requirements tracking software?
It is the part of a life new business system that holds every requirement ordered on every open case and follows it to arrival. A requirement is any piece of evidence the underwriter needs before deciding: from the carrier's requirement grid (by age and face amount) or from something the applicant disclosed. The tracker sits between the order and the vendors. It receives their status feeds, shows each requirement's state, and tells the case manager which ones need her.
The category overlaps with three neighbours, which is why buyers find it hard to compare. A policy administration or new business system often has a requirements screen, but it records orders and receipts rather than predicting arrivals. An underwriting workbench shows the underwriter the evidence once it is in. An outsourced retrieval vendor tracks its own queue of doctors' offices and nothing else. A tracker earns its place by covering every requirement from every source in one view, and by dating each one honestly.
Underwriting requirements for life insurance: who supplies each, and the rule behind it
Every requirement has an outside supplier and most have a legal basis that governs how it is ordered. A tracker that knows the supplier knows the pace; one that knows the rule knows what must be on file before the order can go out. The table lists the usual requirements on a fully underwritten case.
Underwriting requirements on a fully underwritten life case
| Requirement | Who supplies it | What must be in place first | Sample pace, p50 / p80 |
|---|---|---|---|
| Part 2 interview | Paramedical vendor, by phone | The application; the applicant's time | 3 / 5 days |
| Paramedical exam | Paramedical vendor, at home or office | An appointment the applicant keeps | 8 / 11 days |
| Blood and urine profile | Laboratory, from the exam draw | The exam | 2 / 3 days from the draw |
| Attending physician statement | Doctor's office, through a retrieval vendor | A signed HIPAA authorization | 12 to 26 days median, by office |
| Motor vehicle report | State driving records, through a vendor | Federal law permits use for underwriting | Seconds |
| Prescription history and MIB | Consumer reporting companies | The applicant's authorization and notices | Seconds |
| Inspection report | Inspection company | Federal disclosure rules if it is investigative | 9 / 12 days |
| Financials, forms, trust papers | Applicant, accountant, producer | The carrier's request | Set by people, not feeds |
The right-hand column is the argument for the whole category. Three requirements return in seconds and need no tracking at all. Three more run on vendor schedules that are fast and steady. The APS is the outlier: slow, variable by office, and supplied by someone with no contract with the carrier. A tracker that treats all eight the same way spends its attention where nothing happens.
Why "pending" says nothing about an APS
A doctor's office has no legal duty to answer an insurer's records request on any timetable. HHS guidance on the HIPAA rules sets the two routes side by side: a disclosure under the patient's authorization "Permits, but does not require, a covered entity to disclose PHI", while a patient's own access request must be acted on within 30 days. The insurer's request travels the first route. The office answers when its records desk gets to it.
That is why the vendor status feed for an APS reads "pending" for weeks without being wrong. The request was received, it is in a queue, and nothing in the feed says whether the queue is moving. The useful questions are different: how long does this office usually take, how long has this request been here, and when did its status last change? Software that cannot answer those three questions is a list, not a tracker.
How should a requirement be dated? From its own source's last 90 days
Date each requirement from the recent history of the exact source that holds it: that vendor, or that doctor's office. In the solution the expected date is the order date plus the source's median turnaround over the last 90 days, and the slow date is the order date plus its 80th percentile. Two more rules turn the dates into actions: a requirement with no status change for four days is stalled, and one past its slow date is late.
Four rules that turn a vendor feed into dates in New Business Case Management
| Rule | How it is set | Worked on the sample APS | What a person can change |
|---|---|---|---|
| Expected date | Order date + the source's median (p50) | Ordered 29 Sep + 17 days = 16 Oct | Shown at p50 by default; p60 or p70 are settings |
| Slow date | Order date + the source's 80th percentile | 29 Sep + 24 days = 23 Oct | Fixed: the line after which the requirement is late |
| Stalled | No status change for 4 days | Invoice on 8 Oct, nothing since: stalled on 12 Oct | The threshold steps up or down by a day |
| Thin history | Fewer than 5 requests in 90 days | Not needed: Lakeview answered 23 | The source borrows the vendor's regional average |
Two choices in those rules matter more than they look. The window is 90 days because offices change: a records clerk leaves, a practice moves to a new records system, a hospital group takes over billing. A year of history averages over those changes; a month is too few requests for most offices. And the dates are recomputed every morning, so a tile can move later when its source slows down. On the sample Monday the 07:02 run moved three dates later, and the case manager saw it before any producer did.
Why the median and the 80th percentile, not the average
Turnaround is skewed: most requests come back in a band, a few take far longer. One 60-day request drags an office's average up and makes every future date too pessimistic; a run of quick ones drags it down and makes dates too hopeful. The median ignores the outliers when setting the expected date, and the 80th percentile uses them where they belong, in the slow date.
Summit Cardiology in the sample shows why both numbers are needed. Its median is 26 days and its 80th percentile 38: a wide spread, meaning a request there is genuinely uncertain. Riverbend's is 12 and 16: a narrow band, meaning a Riverbend request four days past its expected date is more alarming than a Summit one. A tracker that shows one number per source hides the difference. A tracker that shows both lets the case manager treat each office as what it is.
What is a stalled requirement, and how is the reason found?
A stalled requirement is one whose status has not changed for longer than the stall threshold, four days in the sample setup. Stalls are different from lateness. A late requirement has run past its slow date; a stalled one may still be inside its window but has stopped moving, which is usually the earlier and cheaper moment to act.
The vendor feed behind a stall, and where its dates come from
Finding the reason is the part that saves the week. In the sample case the last line of the vendor feed was an invoice: a $65 copy fee, payment before release. The tracker marked the APS stalled on its fourth unchanged day and wrote the reason on the tile, and because $65 is above the agent's $50 limit the fee went to the case manager to approve. The flow below is the whole loop, with the person's steps marked.
One stalled requirement, from the feed to an action
Agent
Requirement trackerReads every vendor feed hourly and re-dates each open requirement from its source's last 90 days.
Never: Never cancels or re-routes an order
Agent
Requirement trackerMarks the tile stalled after four days without a status change and reads the vendor's note for the reason.
Agent
Follow-up agentDrafts the follow-up to whoever can move it, and approves a records fee if it is within the limit.
Never: Fees above $50 go to the case manager
A person decides
Case managerApproves the $65 fee, or chooses another route: re-send the authorization, phone the office, collect in person.
Agent
Follow-up agentTells the retrieval vendor, who pays the office and asks for release the same day.
Can software predict when an APS will arrive?
It can give an honest range, not a promise. An office that answered 23 requests in 90 days with a median of 17 days will, on its own recent form, return about half of new requests within 17 days and about eight in ten within 24. That is a forecast with a known error, and it is far better than a fixed allowance, but it does not make the office faster and it cannot see a records clerk's holiday.
The way to know whether the forecast deserves trust is to test it on cases that have already closed: date each requirement as the software would have on its order day, then check what share really arrived by the expected date and by the slow date. If the dates are well set, about half arrive by the median and about eight in ten by the 80th percentile. The method, and what to do when the numbers miss, is in life insurance cycle times.
Accelerated underwriting left the slow cases for the tracker
Accelerated programs took the simplest cases out of full underwriting, so the cases that still need tracking are larger, older and more often impaired. The Society of Actuaries' 2022 survey of accelerated underwriting practices, which polled 24 direct writers and was written by Milliman actuaries, found that "Twenty-two direct companies (out of 24) indicated that they made changes to their AU program between 2020 and 2022", and that the "Average maximum face amount increased from $800,000 to $2,100,000."
The same survey found that the most common maximums were still a $1,000,000 face amount and issue age 60. Above a program's limits a case goes back to full underwriting: the exam, labs and, where the answers call for it, an APS. For a tracker that means fewer cases with more requirements each, and a larger share of requirements from doctors' offices, the slowest and least predictable source in the table above.
What to look for in underwriting requirements tracking software
Judge a tracker on its dates, its stalls and its limits, in that order. The checklist is written so each item can be tested on a sample of your own closed cases before you sign anything.
Eight tests for any underwriting requirements tracker
- Dates come from each source's own history
Per vendor and per doctor's office, not one standard allowance per requirement type.
- Both a median and a slow date
One number per source hides how uncertain that source is.
- Thin histories are handled
An office with three requests should borrow a regional average, not set dates from one case.
- Stalls are measured by status age
Days since the last status change, separately from days since the order.
- The reason is read, not just the code
A fee request, a missing authorization or a wrong address sits in the vendor's note.
- Every date names its source
The case manager and the auditor can see why the date is what it is.
- Limits on what software may do
Fee approvals capped, no cancelling or re-routing orders, no contact with the applicant about health.
- Replay on your closed cases
Ask for the share of requirements that arrived by the expected and slow dates on last quarter's files.
Be equally clear about what a tracker cannot do. It does not make a doctor's office faster; it makes the wait visible and the stalls short. It needs status feeds from your paramedical, lab, inspection and retrieval vendors, and a source with almost no history will carry a borrowed date for a while. And it is not a replacement for the retrieval vendor's people, who still phone records desks and collect in person. What a carrier brings to start, from the requirement grid to the feeds, is listed in life insurance case management software. To see the tracker's dates on sample cases, start from New Business Case Management.
Turnaround by source: where every expected date comes from
Questions people ask
What is a pending requirement in life insurance?
A requirement the underwriter needs that has been ordered but not yet received or reviewed, such as an exam, lab results or a doctor's records. "Pending" is a status, not a forecast: an APS can sit pending for weeks while the office waits for a fee or a re-sent authorization.
How long do paramedical exam results take to come back?
We found no public national figure; it depends on the vendor and the applicant's schedule. On the fictional sample carrier, exams ran a median of 8 days from order and lab results 2 days from the blood draw, which is why the exam appointment, not the lab, sets the pace.
What is a requirements tracking sheet?
A spreadsheet many new business teams keep beside the policy system, with one row per case and a column per requirement, updated by hand from vendor portals. It holds the real notes but has no dates of its own, so it shows what someone last wrote, not what is late.
How do case managers chase underwriting requirements?
By phone and email to vendors, through the retrieval vendor for doctors' offices, and through producers for forms. A fixed cadence helps: in the sample setup, routine vendor follow-ups go on day 0, day 3 and day 5, and anything unusual is drafted for the case manager to send.
Does tracking software order the requirements too?
Some only track. In New Business Case Management a separate application reader orders requirements from the carrier's grid and the applicant's answers, recording the answer that triggered each order, and the tracker dates them from the moment they are placed.
Does it replace the APS retrieval vendor?
No. The retrieval vendor's desk still requests, pays and collects records from doctors' offices. The tracker reads that vendor's feed, dates each request from the office's own history and sends the vendor one clear ask when a request stalls.