Start with one rule family.
Agree with a design partner on a limited contract change, the evidence needed and the expected result. Identify unsupported clauses explicitly.
✳ DUEMD VERIFY · CONCEPT PROTOTYPEA contract changes.
A contract changes.
Did the system
change with it?
Explore a possible next step for DueMD: turn a rule change into repeatable checks, compare results, and keep the evidence together.
Interactive prototype · Sample data · No payer-system connection
WHY THIS WORKFLOWMake the disagreement
Make the disagreement
specific enough to check.
A useful investigation connects the rule, the input and the result. The concept brings those pieces into one review trail, instead of ending at a highlighted difference.
This prototype explores the workflow. A production version would need authorized integrations, reviewed contract rules and validation with a customer.
TRY THE WORKFLOWOne rule. One mistake.
INTERACTIVE PROTOTYPEOne rule. One mistake.
A traceable way through.
DueMD VerifySample data · No payer-system connection
- 01Define
- 02Test
- 03Freeze sample
- 04Observe
- 05Verify fix
EXPECTED VS OBSERVED
NOT RUNRun the checks to see the difference.
Six scenarios: five financial checks and one scope boundary. Excluded scenarios are not counted as passed financial tests.
Supported scenarios5 / 6
Target checks run0
Payer-system connectionNone
| Scenario | Expected | Observed | Outcome |
|---|---|---|---|
| Day before the change | $100.00 | Not run | Not run |
| First day of the new terms | $108.00 | Not run | Not run |
| Another included service | $172.80 | Not run | Not run |
| Fixed-rate exception | $145.00 | Not run | Not run |
| Product outside the model | Not modeled | Not run | Outside scope |
| Rounding to cents | $133.33 | Not run | Not run |
Earlier runs stay available
No run history yet. Changing the target will not rewrite a completed run.
Monitor after the checked release
Load a clean batch, then deliberately revert the local target model. The old release remains unchanged.
No observations have been generated.
Incident details
The export is labeled synthetic and contains only the prototype scenario and your actions. Nothing is submitted to an insurer.
Ready. Try the initial 100% configuration, then load the matching 108% rule.
CURRENT PRODUCT VS FUTURE DEVELOPMENT
What is built, and what comes next
The public tools, this browser prototype and a production verification product are three different things.
| Capability | Built in the site | Shown in this concept | Needed for production verification |
|---|---|---|---|
| Define a rule | Three checklist templates with editable inputs | One fixed example clause | Document intake, reviewed interpretation and change control |
| Calculate a reference | Versioned CMS lookup within its stated scope; three scenario calculators | Illustrative references and independent control examples | Validation for each supported contract and rule family |
| Compare a target | No payer-system testing | An independent local target model | Authorized adapters and a real test environment |
| Track a change | Checklist exports and documented source versions | Frozen sample runs, a sample release and generated observations | Authentication, access controls, durable audit history and real data ingestion |
| Make a business claim | No paying customers reported; no recurring revenue claimed | A development hypothesis to inspect | Customer validation and independently measured outcomes |
A BUYER'S NEXT STEPValidate one real workflow.
01 / Choose a scope 02 / Connect a target 03 / Measure the value
Validate one real workflow.
Then decide what to build.
Use an authorized test process.
Bring in actual system responses through a reviewed adapter. Validate those responses against independently reviewed expectations before using them operationally.
Compare with the current process.
Check review time, actionable findings and false alarms. These are proposed pilot measures, not outcomes DueMD has already achieved.