For each test, record the inputs, an independently reviewed expected result and the actual system response. Include an ordinary case, the effective-date boundary and an exception. The checklist generator helps prepare these checks; your team runs them in its authorized test process.
Separate the rule from its implementation
The clause tells you what needs interpretation. A reviewed expectation states the intended outcome for a specific input. The system under test produces the observed outcome. Keep those three records distinct.
If the expected result is generated by the exact same unreviewed code as the observed result, both can share an error. Use independent examples and have a qualified reviewer resolve ambiguous terms.
Cover the boundary and the exceptions
Use the day before, the effective date and the day after, while holding the other dimensions constant. Then vary product, entity, setting, component or another material dimension. Do not turn an excluded case into zero payment; it needs the correct alternative rule.
Reference files and component-specific rules need their own context. CMS reference documentation and the therapy reduction example show why a single rate multiplier is not a universal payment model.
Write useful expected conditions
Some tests can have a numeric expected result. Others should deliberately say “review required” because a modifier or exclusion rule has not been supplied. A clear blocked test is more honest than a fabricated expected amount.
The DueMD generator supplies three rule templates and optional dimensions. It uses illustrative reference amounts in calculation checks; it does not create live claims, upload a contract or submit anything to a payer.
Retest unchanged behavior as well
A new amendment can unintentionally change unaffected scenarios. Keep prior control examples and compare them against the proposed configuration. Record which changes are expected and which need investigation.
A release approval should name the tested version, remaining exclusions and reviewer. A passing checklist is not a guarantee of future payment, but a reproducible test record is more useful than “we checked a few claims.”
A five-case test plan
Illustrative example.
| Test | Example input | Expected condition |
|---|---|---|
| T-001 | Day before 108% begins | Old 100% rule |
| T-002 | First effective day; $100 reference | $108 under stated assumptions |
| T-003 | Excluded product | Use correct separate terms; not zero |
| T-004 | Modifier rule not supplied | Review required |
| T-005 | Actual result $100, expected $108 | Difference −$8; investigate |
Expected conditions come from the approved interpretation, not from the payer response you are checking.
Gaps to look for in a test plan
- Using only an ordinary happy-path test.
- Inventing a modifier effect without a source.
- Treating a generated checklist as a completed test.
- Approving a different configuration from the one tested.
Before approving the change
- Identify the changed term and affected scope.
- Approve the expected conditions independently.
- Collect actual results from an authorized test process.
- Retain evidence, exclusions and the tested version.
Keep reading
Sources
Apply the agreement and records relevant to your review. Examples explain the method; they do not determine a payment obligation.
- PFS documentation and files
- Therapy services: multiple procedure payment reduction
- PFS status and payment policy indicators
Need a term or calculation explained?
Read an answer or send a general question about the step you are working on.
Calculator values are not attached. Leave out patient and confidential information.