Study CHAM by training constraint-first case analysis: restate every scenario as one sentence naming its limiting problem, tag each fact to verification, authorization, registration, or documentation, and test each answer option against the constraint and its side effects.
Eligibility Verification, Authorization, and Registration: Concepts That Get Blurred
Patient access management rests on three processes that sound interchangeable but fail in different ways: eligibility verification, prior authorization, and registration. Treating them as one blur makes scenario analysis impossible.
Eligibility verification confirms that a patient's coverage exists and is active for the date of service, and surfaces plan details such as cost-sharing. Prior authorization is a separate act: asking a payer to approve a specific service before it happens. Registration is the creation of the patient record itself — demographics, insurance identifiers, and consents. A department can do all three poorly in different places, and each failure produces a different downstream symptom, which is why naming the process matters before deciding on any fix.
Practice by tagging every scenario fact to its process. A claim rejected for inactive coverage traces to verification; a service denied for lack of approval traces to authorization; a mismatched subscriber name traces to registration. In manager-level questions, this tagging tells you whether the fix belongs in a workflow, a staffing plan, or a training plan. Build the habit with flashcards that give the symptom and ask you to name the failed process, then reverse the direction so retrieval works both ways.
- Verification: is coverage active, and what does the plan require?
- Authorization: has the payer approved this specific service in advance?
- Registration: does the record correctly identify patient, payer, and consent?
- The manager question: which process broke, and where in the workflow did it break?
Reading Access Metrics: Turning a Number into a Nameable Problem
Metric-style scenarios test whether you segment before concluding. An aggregate number rarely points to a fix; a segmented number does. Practice reading any access metric by asking what comparison it is hiding.
Access departments commonly track registration accuracy, denial rates grouped by cause, patient wait or processing times, point-of-service collections, and referral or authorization turnaround. Each metric becomes useful only when broken out: denials by payer and cause, wait times by service line and arrival type, collections by payer class. The skill to drill here is noticing when a scenario hands you only the aggregate and recognizing that your first decision should be to segment the data, not to act on it.
Exercise: write a fictional week of dashboard data — for example, 40 registration-related denials, an average door-to-registration time, and a collections rate — deliberately without subtotals. Before touching any fix list, write three questions you would need answered to act: which payers, which service lines, which shifts or staff. Expected observation: every productive question is a segmentation question, and every tempting immediate fix — a memo, a training session, a discipline step — addresses a population you have not yet identified. Repeating this drill rewires the reflex to act on aggregates.
Manager Applied Practice: Choose the Constraint Before the Fix
The applied-practice scenarios in this section describe a situation with several plausible fixes. The defensible choice addresses the constraint — the specific limiting problem the facts establish — without creating a new problem of its own.
Scenario: registration-related denials rose this quarter, and a supervisor proposes retraining the entire registration team. The better decision: pull the denials apart by payer, cause, and registration date first. Suppose the rise concentrates in one payer's newly issued plan identifiers being entered under an outdated format. The correct response is a targeted worklist and a real-time eligibility edit for that payer — not broad retraining. Why it matters: generic retraining spends staff time on a problem most of the team did not cause, and leaves the actual defect untouched.
The mistake in that scenario is tempting because retraining feels like action. The discipline you are building is the constraint statement: 'the constraint is plan-identifier entry for one payer, so any fix must change how those identifiers are captured or verified.' Write that sentence in every practice scenario before reading the options. Options that ignore the constraint, or that solve it while creating a second problem — for instance, adding a manual step that slows every registration — are the distractors you learn to eliminate quickly.
Methods and Documentation: Correcting the Record Without Creating Rework
The procedure-focused scenarios here ask what to do when a record is wrong or incomplete. The dependable principles are prompt correction through defined workflows, clear escalation paths, and documentation made contemporaneous with the event.
Two ideas carry most of the weight here. First, corrections follow the system's designated amendment or correction workflow, so the change remains traceable; informal edits, or re-creating a record as a duplicate, undermine the audit trail that later reviews depend on. Second, timing matters: an error caught before the encounter closes is far cheaper to fix than one discovered after billing, so escalation expectations should be defined for each discovery point. Manager-level judgment means designing those paths, not merely following them.
Scenario: two days after registration, a registrar notices the insurance subscriber field lists the patient's parent instead of the patient, and the visit has not yet occurred. A tempting choice is to leave it for billing to catch. The better decision: correct the field now through the correction workflow, re-run eligibility for the corrected coverage, and notify the billing team per the escalation path. Why it matters: downstream correction multiplies touches — claim edits, rework, patient statements — and a duplicate registration can fragment the record, affecting every later interaction with that patient.
Ethics and Standards: Separating Financial Conversations from Access to Care
The ethics scenarios here place revenue tasks in tension with a patient's ability to be seen. The defensible response separates the financial conversation from the clinical pathway and fixes the workflow, not just the individual worker.
Scenario: a front-desk employee, pressured about collection targets, begins telling walk-in patients at arrival that they must settle an estimated amount before being seen. The tempting fix is a verbal warning and moving on. The better decision: intervene on the immediate case, then examine the workflow that made the behavior seem reasonable — where the financial conversation is sequenced, what scripts staff receive, and how collection expectations are communicated. Why it matters: a coaching conversation alone leaves the structure that produced the behavior, and the same pressure recreates it with the next employee.
Manager-level standards extend across privacy in open registration areas, equitable use of interpreter services, and consistent handling of self-pay and underinsured patients. The practical move is translating each value into a procedure: a privacy standard becomes screen positioning and quiet check-back scripts; equity becomes documented interpreter workflow steps. In practice scenarios, prefer answers that embed the standard into the process over answers relying on individual judgment in the moment, and prefer escalation to silent tolerance of a questionable practice.
A Case-Analysis Routine and a Technician-versus-Manager Decision Table
Run every case item through the same four steps: identify your role, state the constraint, list the constraining facts, then pick the option that resolves the constraint without spawning a new problem.
Step two is the one worth drilling. A constraint statement names the limiting problem in one sentence: 'the constraint is authorization turnaround for scheduled imaging,' or 'the constraint is a registration script that does not distinguish screening questions from financial questions.' Facts that do not constrain — a detail about the patient's history, a number that changes nothing — should be visibly set aside. That filtering habit is what turns option elimination into a fast test rather than a coin flip among three plausible answers.
Use the table actively, not decoratively. Take any practice scenario — the free practice sets linked below work well — and fill in the third and fourth columns yourself before reading the rationale. If your manager-level response does not fit in one sentence, you have not yet identified the constraint. Over a week of scenarios, review your completed tables and note which cue you mis-classified; those mis-classifications are your study list, and they are more informative than any raw practice score.
| Scenario cue | Technician-level reflex | Manager-level response | Why the difference matters |
|---|---|---|---|
| A metric worsens | Propose training or discipline | Segment the metric and locate the specific failure point | The fix must land on the actual defect |
| A record error is found | Quietly fix it, or ignore it | Correct through the defined workflow and escalate per path | Traceability and duplicates affect all later care |
| Financial pressure meets patient access | Comply, or grant a one-off exception | Separate the financial step from the clinical pathway and revise the workflow | Structure, not warnings, prevents recurrence |
| Two options both sound right | Pick the nicer-sounding one | Test each against the constraint statement | One usually creates a problem the facts already warn about |
A Four-Pass Preparation Sequence with Readiness Checks
Prepare in four passes: concept mapping, metric interpretation drills, timed scenario work, and weak-area repair. Each pass ends with a self-check rubric; treat rubric scores as learning milestones, not pass predictions.
Pass one, roughly a week: build the concept map from the first section and connect each process to its failure symptoms. Pass two: run the dashboard drill daily until constraint statements come automatically. Pass three: work case scenarios against the decision table under time pressure, forcing an option choice even when uncertain. Pass four: revisit only your mis-classified cues and re-drill them. For current administrative details — eligibility, format, fees — consult NAHAM directly at naham.org; this guide deliberately does not restate them.
Adapt the sequence to your own evidence. If your scenario log shows solid concepts but weak metric interpretation, convert pass-three days into dashboard drills. If you have no access to a real department's data, invent plausible weekly numbers — the skill is segmentation reasoning, not facility-specific software, and your workplace systems may differ from any scenario you encounter. Keep the free practice-question link below for fresh cases, and return to the study guide index when you switch subjects.
- You can restate any scenario as a one-sentence constraint before reading the options.
- You can tag every fact in a case to verification, authorization, registration, or documentation.
- Your manager-level responses each fit one sentence and name a workflow, not a person to blame.
- Self-scored rubric (0 = guessed; 1 = constraint found, fix wrong; 2 = constraint and fix both sound): you consistently reach 2 on new scenarios.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.