QMCSO & NMSN: A Notice Desk That Intakes, Checks and Pre-Checks — Then Workflow Qualifies and Enrollment Covers
Notice desk → qualify & cover. An administrator uploads the notice, reviews the read and creates the order; three engines score it; the administrator passes or fails pre-check; the approver qualifies; the enrollment engine covers the child — every stamp on one record.
A court, a state child-support agency or the federal NMSN process sends a medical support notice to the employer. In most organizations it is photocopied to payroll and benefits and tracked on a spreadsheet until somebody remembers the forty-day clock. Benefits Reimagined gives it two rooms that stay in sync: an administrator-only notice desk where the PDF becomes an order with its checks, its clock and its pre-check decision, and the platform's own Workflow and Enrollment, where the order is qualified and the child is covered — never out of sequence, never without a name and a date on the stamp.
Admin-only notice deskOCR intake · Part A / Part B3 engines · admin pre-checkWorkflow qualifies · Enrollment coversState & federal clocks
Reimagining Medical Child Support Orders
"A court, state agency or NMSN process sends a medical support notice to the employer. An administrator uploads the PDF, reviews the read and creates a Medical Support Order. Engines score document validity and fraud; the administrator then passes or fails pre-check. A pass creates a benefit life event and usually a workflow instance. When the approver approves, the order becomes Qualified. Enrollment — the NMSN reason, matching dates and verified children — can then mark it Enrolled. The agency registry stores endpoints; the electronic send to the state is on the roadmap."
2rooms that stay in sync — the administrator-only notice desk, and qualify-and-cover in Workflow and Enrollment
3engines on every save — document validity, fraud detection, pre-check — with their results stored on the order before an administrator decides
1–4children per order from the employee's own dependent record, each under the QMCSO child-type age, student and disability rules
0enrollments out of sequence: the child is covered only after pre-check, qualification and a date-exact enrollment gate
The Working Flow — Who Does What, in Order
Nine steps from set-up to a covered child. Steps 1–6 and 9 live on the administrator-only notice desk; steps 7 and 8 happen in the platform's Workflow and Enrollment. Rows shaded amber are the two screens that store connections and lists rather than send anything — the page says so, and so does the product.
#
Screen / room
Who
What they do
1
Set-up (before the first notice)
Implementation consultant
Seed the regions and child relationship codes; two benefit adjustment reasons flagged QMCSO and NMSN; the QMCSO child type with its age, student and disability rules; the federal SLA row; the legal-document type in the Document Center; an active workflow template for the life event; module access. Then pilot one order end to end.
2
Config · State Rules
Config consultant
One active rule per operating state for orders (and terminations) with the service-level days; the seeded federal NMSN row is read by the engines and protected from create, edit and delete on the screen.
3
Config · eSERV Config
Integration admin
Register each child-support agency: name, state, endpoint and port, real-time or batch, authentication method, PGP key, remote directory. A connection inventory — it sends nothing to the state.
4
Dashboard
Benefits leadership · operations
Read the four live tiles — total, validation pending, deficient, SLA breach — recent orders with the same view, pre-check and delete actions as intake, quick actions and Essential Insights. Not a decision screen.
5
Order Intake · upload & create
Intake admin
Pick the employee, one to four QMCSO children from the dependent record (or add the child in Employee Management first), type and subtype, the PDF; review the OCR read of Part A and Part B; save. The system stores the document once, writes the three check rows and sets the first status.
6
Order Intake · Pre-check
Qualification admin (same desk)
Open a pending or deficient order and PASS or FAIL pre-check. Fail closes the order. Pass on a Medical Support Order creates a benefit life event flagged for the order and, where a template applies, a workflow instance — the order shows Under Review.
7
Workflow (outside the desk)
Workflow approver
Approve the life event → the order becomes Qualified with the qualified date and flag. Reject → Not Qualified. The approver never sits in the notice desk.
8
Enrollment (outside the desk)
Employee · HR on their behalf
Enroll under the NMSN event: qualified order, federal subtype, event dates equal to the order's start and end, at least one verified child on the order → the engine marks the order Enrolled.
9
eSERV Transmit
Operations (planned)
Lists enrolled orders and reuses view, pre-check and delete. The send of Part B or an acknowledgment to the state is on the roadmap — not a go-live desk.
The Clocks and Rules Every Order Is Measured Against
These are the numbers a benefits administrator is held to. In Benefits Reimagined the service-level days live in a state-rules catalog — one row per operating state plus a seeded federal row for the NMSN — and every order carries its notice date, received date and clock from the moment it is saved.
Employer clock20 business daysfrom the date on the NMSN to return Part A with a reason or forward Part B to the plan (45 CFR 303.32)
Plan administrator clock40 business daysfrom the same date to complete the Plan Administrator Response and return it to the issuing agency
Withholding limit50 – 65%of disposable earnings under CCPA Title III — 50/60%, plus 5% with arrears over twelve weeks; many states set lower caps
Qualified means§609(a)(3)names and addresses of participant and each child, a description of the coverage, and the period the order applies to
Enrollment timingAny timean NMSN overrides open-enrollment windows and waiting periods; the change is a permitted Section 125 mid-year election
Employee leavesNotify promptlythe employer tells the issuing agency when a covered employee terminates; COBRA rights follow the plan's normal rules
Electronic NMSNSince Feb 2022the federal e-NMSN program delivers notices by SFTP or system-to-system XML; participation by state is voluntary
Forms2026 refreshParts A and B are under OMB renewal after the November 2025 expiry — expect new expiration dates on notices this year
Sources: 45 CFR 303.32, ERISA §609(a), 29 CFR 2590.609-2, DOL EBSA QMCSO guidance, DOL WHD Fact Sheet #30, OCSS e-NMSN program pages and 2025 Federal Register notices, as of September 2026. Informational only — confirm your procedures with counsel.
Two Rooms, Six Stages
Follow a National Medical Support Notice from the Texas Office of the Attorney General for an hourly employee with two children — from the catalogs a consultant seeds, through intake, the engines and the administrator's pre-check on the notice desk, to the approver's stamp in Workflow and the enrollment that covers the children — then the two config screens, and the same desk serving a plant on another HRIS.
Six catalogs that make a notice processable.
The order desk reads from configuration that other parts of the platform already own. Two benefit adjustment reasons — one flagged for court and agency orders, one for the federal notice — decide which life event a pass creates. A QMCSO child type on the dependent catalog carries the age, student and disability rules a named child must satisfy. A state-rules table holds the service-level days for each state's orders and terminations, with a seeded federal row for the NMSN that the interface protects from edits. The Document Center has a type for the legal PDF, the workflow engine has a template for the event, and the agency registry holds each child-support agency's connection details.
What the consultant seeds, in order
Regions and child relationship codes; a termination action so a terminated employee is refused a new order
Adjustment reasons flagged QMCSO and NMSN — pre-check pass looks them up by subtype
QMCSO child type with age minimum and maximum, student and disability extensions; one state rule per operating state plus the seeded federal row
Document type, workflow template, module access — then a pilot: create, read the engine rows, pass, approve, enroll with matching dates
Why it matters
A notice that arrives before the federal row is seeded has no clock — the seed is part of go-live, not an option.
State rules are unique per state and rule type; the federal row cannot be created, edited or deleted from the screen, so the NMSN clock cannot be changed by accident.
Upload the notice; the order writes itself — then you check it.
The intake administrator selects the employee, picks one to four children from that employee's dependent record — or opens Employee Management in a new tab to add the child first — chooses the order type and subtype, and uploads the PDF. The document lands in the Document Center once, under its own type, and can never be attached to a second order. Optical character recognition reads Part A and Part B into a review screen: agency, case number, court or notice dates, custodial parent, each child, coverage types. The administrator corrects what the scan misread and saves; the start date must equal the notice date, the court order ID must be unique across the tenant, and a federal notice may not carry an issuing state.
What intake insists on
An active employee — a terminated employee cannot receive a new order
One to four named children who exist on the dependent record and pass the QMCSO age rules
One unused legal PDF, one globally unique court order ID, an issuing authority and a premium responsibility
Federal notices without an issuing state; court and agency orders with one, in the state's document format
Why it matters
Everything the engines will test is captured at intake — nobody re-keys the notice for payroll or the plan later.
The order list filters by employee, type and status; view, pre-check and delete sit on each row, and only pending or deficient orders can be deleted.
Three engines write; the administrator passes or fails.
Saving an order writes three check rows. The document-validity engine confirms the notice names an agency and a case, that the dates are in order, that the employee and children are present, that the document level and format match the subtype, and that coverage is described. The fraud-detection engine compares each child's name, Social Security number and date of birth to the HR record, flags a subtype that contradicts the document, and searches for the same court order ID or the same case-and-children pair on another order. The pre-check engine confirms the employee was active and enrolled on the notice date, that the custodial parent's address is usable, and that the notice-to-received interval is inside the service level. Age failures set Not Qualified; fraud or document failures set Deficient; a past end date closes the order; otherwise it waits as Validation Pending for a person.
What pre-check enforces
The order must be Validation Pending or Deficient; the decision is PASS or FAIL only; a second pass on an already-passed order is refused
A deficient order can be fixed at the source — the dependent record, the notice — and re-read
Pass needs the court order ID and premium responsibility, an active benefits record and an adjustment reason flagged for the subtype; if the life event cannot be created, the pass is blocked
Fail closes the order; the pre-check row stays Pending in the record until a person decides — engines never close the gate
Why it matters
An order is never qualified by a clean scan. The engines score; the administrator passes or fails; the approver qualifies.
Athena on this desk explains why a check failed and which record to fix, and drafts the note — it does not pass or fail an order.
Qualified in Workflow, covered in Enrollment — outside the desk.
A pass creates a benefit life event flagged for the order and, where the template applies, a workflow instance; the order shows Under Review until the approver acts. Approval writes Qualified, the qualified date and the flag the plan relies on; rejection writes Not Qualified. Neither enrolls anyone. Enrollment is its own step with its own conditions: the adjustment reason must be the NMSN reason, the order must be Qualified with the federal subtype, the event's start and end dates must equal the order's, and at least one selected child must be on the order's dependent-verification record. Only then does the enrollment engine mark the order Enrolled — and the premium becomes a permitted mid-year deduction beside the rest of the employee's elections.
What the record holds afterwards
Qualified date, qualification status and the approver's decision from the workflow instance
Health plans enrolled under the order, read-only on the order once enrolled
Termination notice received, termination date, and the employee's continuation choice when the order ends
The full history: intake, each engine row, pre-check decision, approval, enrollment, closure
Why it matters
The child is covered exactly once, under exactly the dates the order states — and the record shows who allowed it.
Because payroll and enrollment share the platform, the withholding test and the pre-tax deduction use the same election the plan sees.
Two catalogs the desk reads — clocks that are live, a registry that waits.
State Rules is the per-state service-level registry: one active row per state for orders and, where used, terminations, chosen from the platform's region list and unique per state and rule type. Create uses the days to cap an NMSN end date; pre-check and the dashboard's breach tile use them to count the clock. The federal NMSN row is seeded at implementation and the screen refuses to create, edit or delete it, so the federal clock cannot change by accident. eSERV Config is the agency connection registry — enabled flag, agency name and state, endpoint and port, real-time or batch, authentication method, token or credentials, PGP key and remote directory. It persists the connection and nothing more: the transmit desk lists enrolled orders, and the send itself is on the roadmap.
What each screen holds
State Rules — state, rule type (order or termination), service-level days, active flag; the federal row read-only
eSERV Config — one row per agency with mode, authentication and keys; last-sync and status fields stay empty until the send is wired
eSERV Transmit — the enrolled-orders list with view, pre-check and delete; no send button that does anything today
Insights on both config pages from BR Intelligence; the KPI tiles on these pages are illustrative in the current release
Why it matters
A client hears 'connection inventory', not 'live state feed' — and the clock the auditor asks about is the one the engines actually read.
Due-date notification fields exist on the state rule and are not yet consumed; the dashboard's breach tile is the live signal.
SAP-native. Ready for every HRIS a notice can name.
Child-support agencies find employers through new-hire reporting, so a notice can name an employee at any entity on any payroll. The order desk reads the employee, the employment status, the dependents and the elections from the Benefits Reimagined data model. On SAP SuccessFactors Employee Central those fields are live; for an acquired plant on Workday, a division on UKG, or payroll on ADP, Dayforce or Paycom, the HRIS Sync control plane fills the same canonical fields and IntelliMap shortens the mapping — so the fraud engine compares the notice to the same record regardless of the system behind it.
What stays the same across systems
One intake desk, one set of engines, one state-rules catalog for every entity in the tenant
Termination status from any HRIS blocks a new order and drives the agency notification
The child added in Employee Management is the child the enrollment engine verifies
One notice desk, one Workflow, one Enrollment — the child added in Employee Management is the child the gate verifies
Why it matters
A merger or a payroll change should not mean a second mailroom for court orders.
The agency registry is per state, not per HRIS — an Oregon notice for a Workday employee and a Texas notice for a SuccessFactors employee follow the same path.
The Rules of the Desk — What the System Enforces
Nine rules a benefits administrator should know before the first notice. Each is enforced by the engines, the server or the gate — not by a checklist — and each says plainly what the platform does and does not do.
Rule
What the system does
What it means for you
An administrator's app
The desk admits platform administrators and users with header access; everyone else is routed to Employee Home.
No employee self-intake — do not promise it.
Type is Medical Support Order
Orders persist as a Medical Support Order or a Terminated order; QMCSO is the qualified outcome — a status and a flag with a date.
The record shows when, and by whom, a notice became qualified.
NMSN is federal
A federal notice carries no issuing state and the federal document format; a court or agency order needs a state and the state format.
The wrong document level fails create — before the clock starts.
Start date = notice date
The server validates it; the end date cannot precede it and an NMSN end date is capped by the federal service level.
The coverage window on the order is the window the notice states.
One PDF, one court order ID
A document is bound to one order; a court order ID is unique across the tenant.
Duplicate paper is caught at save, not at enrollment.
Pre-check waits for a person
The three engines write their rows and leave pre-check Pending; only an administrator's PASS or FAIL moves it.
A clean scan never qualifies an order on its own.
PASS starts a life event, not coverage
Pass creates the event and usually a workflow instance; approve writes Qualified; reject writes Not Qualified.
Coverage comes later, after Qualified — never from the pre-check click.
Enrollment dates must match exactly
The gate needs the NMSN reason, a qualified federal order, event dates equal to the order's, and a verified child.
A one-day slip blocks plan create — fix the order or the event, not the rule.
Config is not a send
The agency registry stores connections; the transmit desk lists enrolled orders; the electronic send is on the roadmap.
Part B and acknowledgments go through the agency's portal or by mail today.
Nine Screens, One Order Record
Seven screens on the notice desk — Dashboard, Order Intake, the order view, State Rules, eSERV Config, eSERV Transmit — and two rooms outside it that act on the same order. The amber tags mark what is on the roadmap rather than in the release.
1
Dashboard
Leadership's daily view: four live tiles — total, validation pending, deficient, SLA breach — a welcome banner, quick actions to intake, state rules and the transmit list, Essential Insights, and recent orders with view, pre-check and delete.
4 live tilesRecent orders
2
Order Intake · upload
The inbox and the factory: employee, one to four QMCSO children from the dependent record, type and subtype, the PDF into the Document Center under its own type, OCR review of Part A and Part B, then create — with intake insights from BR Intelligence beside it.
OCR · Part A / B1–4 childrenIntake insights
3
Order Intake · list & Pre-check
The orders table filtered by employee, type and status; view, pre-check and delete per row. Pre-check is PASS or FAIL on a pending or deficient order; delete only on those two statuses.
PASS · FAILDelete guarded
4
Order view
One order, six tabs: details, the document (opens in Document Management), pre-check with the three engine rows, dependent verification, benefits (read-only once enrolled) and the full history with notes.
6 tabsHistory · notes
5
State Rules
Per-state service-level registry for orders and terminations, unique per state and rule type, with the seeded federal NMSN row protected from edits; insights from BR Intelligence.
Per-state SLAFederal row protected
6
eSERV Config
The agency connection registry — name, state, endpoint, port, real-time or batch, authentication, PGP key, remote directory — persisted for the day the send is wired.
Connection inventoryRoadmap: send to agency
7
eSERV Transmit
Lists every enrolled order and reuses view, pre-check and delete. The Part B and acknowledgment send is on the roadmap; the screen is not a go-live send desk.
Enrolled listRoadmap: transmit
8
Employee Management & Document Center
Outside the desk but on the same order: add or edit the QMCSO child on the dependent record in a new tab; open the legal PDF where the plan can find it.
Child masterLegal PDF
9
Workflow & Enrollment
Outside the desk, on the same order: the approver's decision writes Qualified or Not Qualified; the enrollment gate writes Enrolled only when reason, subtype, dates and a verified child agree.
Approve → QualifiedGate → Enrolled
Mailroom & Spreadsheet vs. an Order Desk
Payroll vendors treat a medical support notice as a garnishment; benefits outsourcers treat it as a service ticket. Here is what changes when it is a record in the platform that enrolls the child.
Moment
Mailroom, payroll vendor or outsourcer
Benefits Reimagined QMCSO
A notice arrives
Mailroom → photocopy → payroll and benefits inboxes.
Uploaded once; OCR reads it; the order exists with its clock before lunch.
Is it the right child?
Someone eyeballs the name against the census.
Fraud engine compares name, SSN and date of birth to the HR record and flags duplicates.
Is it qualified?
A judgment call in an e-mail thread.
Validity engine checks §609(a) elements; an administrator passes; an approver qualifies — all recorded.
The forty-day clock
A calendar reminder, if one was set.
Service-level days per state on the order; pending, deficient and breach counts on the dashboard.
Enrolling the child
Benefits keys it in and hopes the dates match payroll.
Enrollment gate: qualified order, matching dates, verified child — or it does not enroll.
The deduction
Payroll estimates disposable earnings from a second system.
Same platform: withholding tested on the real earnings; premium is a permitted mid-year change.
The employee leaves
Someone remembers to tell the agency.
Termination blocks new orders and sits on the record with the continuation choice.
An auditor asks
Which folder? Which year?
The order history: intake, engine rows, decisions, approval, enrollment, closure.
BR Intelligence on the notice desk
Ask Why an Order Is Deficient Before the Clock Runs Out
Order Intake, State Rules and eSERV Config each carry insights from BR Intelligence, and the platform's Athena for administrators sits beside them. It reads the engine rows, the state rules and the order history, explains a deficiency in plain language, points to the record that fixes it, and drafts the note — while the pass, the approval and the enrollment stay with people.
"Why is Dana K.'s order deficient?" — the fraud row: the child's date of birth on the notice differs from the dependent record by one digit
"Which orders breach their clock this week?" — notice date plus the state's service-level days, listed by agency
"Can this NMSN enroll today?" — qualified, federal subtype, event dates equal to the order, a verified child: each condition checked and named
"What did we tell the Texas OAG last time?" — the order history and notes for that agency's prior orders
"Draft the deficiency note" — a note for the order's history, ready for the administrator to keep or edit
Why is the Cook County order for Dana K. deficient?
Athena · from the order's check rowsThe fraud-detection row failed on child identity: the notice lists Elena K. with a date of birth of 03/14/2018; the dependent record has 03/14/2019. Name and Social Security number match, so this is most likely a transcription error on one side. Document validity and pre-check both computed pass. The order's clock — Illinois, 20 business days from 09/02 — has 9 business days left.
If the record is corrected, can it enroll under the October event?
AthenaNot yet. After the correction the order can be passed and routed for approval; it must be Qualified first. Then the enrollment gate needs the event dates to equal the order's 09/02/2026 start and 08/31/2027 end — the October event currently starts 10/01, so it would not match. Create the event from the order's dates, or use the life event that pre-check creates. I've drafted the note; I don't pass orders or create events.
Review the noteShow the enrollment conditions
Ask about any order, check, clock or agency…
What QMCSO Administration Changes
From the mailroom to a record
A notice becomes an order with an employee, children, dates and a clock the moment it is saved — not a photocopy in two inboxes.
From eyeballing to engines
Document validity, fraud detection and pre-check run on every order and leave their evidence on it.
From a judgment call to a decision
An administrator passes, an approver qualifies, the enrollment engine covers — three people, three stamps, one history.
From a reminder to a clock
Twenty and forty business days from the notice date, per state, counted on the dashboard.
From two systems to one deduction
The premium is a permitted mid-year change on the same platform that tests the withholding limit.
From a folder to an audit trail
Intake, checks, decisions, approval, enrollment and closure on the order — for the agency, the plan and the auditor.
Four Stories the Desk Tells
The same two rooms, told the way administrators live them. Consultants seed the desk, intake administrators run it, approvers qualify in Workflow, employees enroll — the same roles whether the employer is one company or a shared-services center handling notices from every county court and state agency.
A consultant stands up the NMSN — the adjustment reason flagged NMSN for the life-event code HR will use; the seeded federal rule with its service-level days (20 or 40 — the client's counsel decides); the QMCSO child type; the legal-document type; a workflow template on the event. Then a pilot notice with federal document flags and a start date equal to the notice date.
An administrator intakes a Texas court order — order plus court subtype, the employee, two QMCSO children, Texas as the issuing state, the state-format PDF; OCR review of the order ID, authority, children, custodian and notice date. Save → the fraud engine finds a child-name mismatch → Deficient. The administrator fixes the name in Employee Management, or fails, or passes with eyes open. Pass → life event → Under Review → the approver approves → Qualified → the employee enrolls the named children.
An NMSN enrollment is blocked — the order is Qualified but ends 12/31 and the event ends 12/30. The enrollment engine finds no order whose dates equal the event's and refuses plan create. The administrator corrects the dates on a new order or the event — there is no fuzzy window, by design.
An integration administrator fills the registry — a Texas OAG row: batch, SFTP, PGP key, remote directory. The last-sync field stays empty; the transmit desk lists enrolled orders; the send is roadmap. It is sold as connection inventory, not a live feed.
Bring a Real Notice. Watch It Become a Covered Child.
Bring one redacted NMSN or court order. We'll upload it, review the OCR read, show you the three engines' rows, pass pre-check, approve the life event, and walk the enrollment gate — with the clock counting the whole way.
NMSN · court · agency orders3 engines on every savePer-state service levelsDate-exact enrollment gate
QMCSO & NMSN FAQs
A Qualified Medical Child Support Order is any court or agency order for a child's health coverage that a plan administrator has determined meets ERISA §609(a) — it names the participant and each child with addresses, describes the coverage, and states the period. The National Medical Support Notice is the standardized federal form state child-support agencies use; an appropriately completed NMSN is deemed a QMCSO. In Benefits Reimagined both arrive the same way — a notice is uploaded, read, checked and qualified — with the NMSN treated as a federal document and a court or agency order as a state-specific one.
Federal rules give the employer 20 business days from the date on the notice to either return Part A with a disqualifying reason or forward Part B to the plan, and the plan administrator 40 business days from the same date to complete the Plan Administrator Response. Benefits Reimagined stamps the notice date, the received date and the state or federal service-level days on every order, and the dashboard counts the orders approaching or past their clock.
Under ERISA §609(a)(3): the name and last known mailing address of the participant and of each child (a state agency's address may substitute for the child's), a reasonable description of the coverage to be provided or how it is to be determined, and the period the order applies to. An order may not require a benefit or option the plan does not otherwise offer. The document-validity engine reads the uploaded notice for exactly these elements before an administrator decides.
No. The notice binds the employer and the plan; the child is enrolled without regard to open-enrollment windows or waiting periods, and the premium is withheld from the employee's pay. Because the enrollment is a permitted mid-year election change under Section 125, the deduction can be pre-tax. Benefits Reimagined starts the enrollment as a life event tied to the order, so the child's coverage is never dependent on the employee opening a portal.
The Consumer Credit Protection Act caps withholding at 50% or 60% of disposable earnings (55% or 65% when arrears exceed twelve weeks), and many states set lower limits. When the premium would breach the limit, Part A is returned with that reason instead of enrolling the child. Because Benefits Reimagined sits beside payroll, the withholding test uses the employee's actual disposable earnings rather than an estimate.
Three engines run the moment an order is saved. Document validity confirms the agency, case, dates, employee, children, document level and format, and coverage. Fraud detection compares each child's name, Social Security number and date of birth to the HR record, catches a wrong subtype, and finds duplicate court orders or case-plus-children pairs. Pre-check confirms the employee was active and enrolled on the notice date, the custodian's address is usable, and the notice-to-received clock is inside the service level. Their results are stored on the order; the administrator's pass or fail is a separate, recorded decision.
A benefit life event flagged for the order is created and, where a workflow template applies, routed for approval. The approver's decision writes the outcome: approved orders become Qualified with a qualified date; rejected orders become Not Qualified. Only a Qualified order can be enrolled, and the enrollment engine insists that the event dates equal the order's start and end dates and that at least one selected child is on the order's dependent-verification record before it marks the order Enrolled.
One to four children from the employee's dependent record, each flagged with the QMCSO child type so the age, student and disability rules configured for that type apply. If the child is not yet on the record, the administrator adds them in Employee Management and returns to the order; the fraud engine then verifies the new record against the notice.
A terminated employee cannot receive a new order, and the employer must promptly notify the issuing agency when a covered employee leaves. Orders carry termination-notice, termination-date and continuation-choice fields, and an order whose end date has passed closes automatically. Ended orders are kept for audit; only pending and deficient orders can be deleted.
The eSERV configuration registry stores each agency's endpoint, port, transmission mode (real-time or batch), authentication method, PGP key and remote directory, and the transmit desk lists every enrolled order. Electronic delivery of the response file to a state agency is on the roadmap; today the registry is a connection inventory and the response is sent through the agency's own portal or by mail.
No — it is the outcome. The order is stored as a Medical Support Order (or a Terminated order) with a subtype that says who issued it: a National Medical Support Notice, a court, an agency or another source. Qualified is a status and a flag that the workflow approver's decision writes, with a qualified date. Keeping the type and the outcome apart is what lets the record show exactly when, and by whom, a notice became a qualified order.
Two rooms. The notice desk — an administrator-only application where intake administrators upload, read and create orders and pass or fail pre-check, config consultants keep the state rules, and integration administrators keep the agency registry. And qualify-and-cover, which happens outside that desk: the workflow approver qualifies the life event a pass creates, and the enrollment engine covers the child. Courts and agencies never log in, and employees cannot open the desk — a terminated employee cannot receive a new order at all.
Yes. The order reads the employee, the dependents and the employment status from the Benefits Reimagined data model. On SAP SuccessFactors Employee Central those fields are live; for Workday, UKG, ADP, Dayforce, Paycom or any other HRIS the HRIS Sync control plane fills the same canonical fields, so one intake desk serves every entity.
The Notice Sets the Clock. The Record Proves You Beat It.
Medical child support orders handled where the child's coverage and the employee's deduction already live — on SAP SuccessFactors today and on whichever HRIS your next entity brings.