Ride record
What service happened?
The record of a transportation service. It may lack information needed for billing or reporting.
Cascadia Claim Integrity / Case study
Turn scattered records
into a clear next step.
A trip record says the ride happened. It does not establish that the claim is complete, ready to send or paid. This build separates those questions so the next step is supported by evidence.
- Make the gap explicit: find the missing billing fact or recipient decision.
- Make the action specific: obtain support, correct the record or request the response.
Synthetic demonstration. Project records and client health plans are synthetic. Real organizations appear only as industry examples. Scenario rates do not estimate real-world prevalence.
01 / Why this matters
A completed ride does not guarantee payment.
Non-emergency medical transportation (NEMT) helps eligible people reach medical care when they need transportation assistance. A scheduled ride to a medical appointment is one example.
The financial consequence
The service must be supported before it can be reimbursed.
For a covered ride, missing required documentation can delay or prevent reimbursement. Completing the trip alone does not establish a payable claim.
- Who: identify the member and the billing provider.
- What happened: document the service, date, locations and supported quantity.
- What is required: meet the program’s coverage, authorization and billing rules.
Which programs?
- Medicaid: covers qualifying transportation under state program rules. Coverage guide ↗
- Medicare Advantage: transportation benefits depend on the plan. Example: transportation benefit programs ↗
The people and organizations
Who is the client, and who does what?
In this model, the client is a health plan. It hires and pays a transportation broker to manage rides for its members. The patient receives the service; a ride company performs the transportation.
Funding and payment Transportation
Where are the records? Each organization holds a different part. See the record flow ↓
The six synthetic clients use the health-plan route. Cedar Harbor is fictional; NEMT identifies the transportation broker; Uber and Lyft are ride-company examples. Each payment follows its own agreement.
The six fictional health-plan clients
- Cedar Harbor Health Plan
- Juniper Way Health Plan
- Alder Ridge Health Plan
- Willow Bay Health Plan
- Maple Vale Health Plan
- Cypress Grove Health Plan
These display names preserve the original account identifiers, contract rules and reporting destinations.
Sources and payment context
- SafeRide describes transportation programs for health plans, including billing and reporting.
- Medicaid describes contracts and per-member payments from states to managed-care plans.
- Medicare & You explains payments to Medicare Advantage plans.
This example covers Medicaid and Medicare Advantage transportation benefits. A claim, a payment and an encounter reporting obligation remain distinct.
The missing connection
Where do the records come from?
The ride company sends a trip record, not a complete healthcare claim. The NEMT team combines it with the health plan’s member and benefit information and its own billing and payment records.
Three sources. One connected claim.
After submission: the health plan or reporting recipient returns a payment decision or reporting response. It may arrive through an intermediary. Without that response, the outcome remains unconfirmed.
Illustrative responsibilities in the health-plan model. The build uses synthetic source records. A ride cost, a claim charge and an actual payment are different facts; none can substitute for another.
Why not one complete record from every company?
- Different jobs: a ride receipt records a trip; a claim also has to satisfy healthcare billing requirements.
- Different rules: state, plan and contract requirements vary. The same trip record may support one use and need more information for another.
- Different handoffs: supporting references and responses can arrive separately or through another organization.
The modeled gap: some operators already integrate these records. This build addresses the situation where the complete, supported claim record is not available.
Background: CMS describes separate documentation responsibilities and varying state and broker requirements ↗Start here / Three terms
From a completed ride to a usable record
Claim
What supports payment?
A structured record supporting a request for payment. This build assembles claim facts from ride records and supporting evidence.
Encounter
What must be reported?
A record of a service used for health plan or state reporting. This build models that reporting downstream of claim preparation.
A recipient can accept a submission without establishing payment or proving every fact correct. These are model explanations, not a claim of actual payer submission or standards certification.
02 / Objective and approach
Connect the record to the decision it supports.
The objective: assemble a supported claim, identify what stops its next step and trace the encounter report built from those facts.
- 01Gather the facts
Retain the ride and supporting records.
- 02Assemble the claim
Show the basis for each required fact.
- 03Check readiness
Identify missing or conflicting information.
- 04Trace the submission
Keep the exact claim version that was sent.
- 05Read the response
Separate confirmed outcomes from limited visibility.
- Connect: link the source information, claim and submission.
- Explain: show the missing fact or conflicting information behind a status.
- Inspect: open the supporting record in the interactive module.
03 / The main finding
Find the missing information before chasing the outcome.
Largest submission-readiness gap
2,668
of 2,682 blocked or conflicting encounter-submission units lack required vendor-payment evidence.
Investigate the payment-data handoff.
- Observed: one synthetic client profile lacks required evidence of payment to the transport vendor.
- Meaning: the payment is unknown. That does not establish that the vendor is unpaid.
- Next action: investigate where that evidence originates and when it arrives.
This is an encounter-submission rule in the synthetic model, not a universal Medicare or Medicaid payment requirement. No recovered revenue is estimated.
Inspect readiness and affected records ↗A unit is one service component for one recipient and purpose, not one distinct claim or ride. Missing-fact categories can overlap.
Finding scope
- All six fictional health-plan clients; full service period.
- July 21 business and knowledge cutoffs.
- Encounter-submission stage.
One ride / Cedar Harbor Health Plan / Recorded synthetic example
A ride record is present. The billing-party identifier is missing.
The patient’s ride has a date, distance and member record. The missing billing reference identifies the party billing for the service. It is not the ride receipt or proof of payment.
- 1Blocked
July 14: claim version 1
The required billing-party identifier is unknown.
Decision: obtain the billing reference before sending. - 2Ready to send
July 16: claim version 2
The reference arrives. A new claim version links that identifier to its source record and passes the modeled readiness rules.
Decision: send version 2; retain version 1 as the earlier state. - 3Rejected
The recipient returns a decision
The response confirms rejection but contains no reason code or explanation.
Decision: request the rejection reason before choosing a correction.
What the analysis adds: a missing fact points to evidence follow-up; a supported new version can move forward; a rejection points to recipient follow-up. These are different queues, not one generic “failed claim” status.
“Supported version” means a preserved claim copy with traceable facts under this model’s rules. It does not guarantee recipient acceptance. This record’s rejection cause is not established in the frozen data.
Follow the actual record ↗Two deeper examples: accepted errors and multiple reporting destinations
Module example 5 / Focused test cases
Accepted, with an error still present.
- DEMO02 distinguishes an upstream claim error from a downstream projection error. A payload can faithfully copy a wrong claim, or change a correct claim during submission. Separate comparisons identify these paths.
- The public golden miniatures and isolated diagnostic copy are explicitly labeled. Their receiver acceptance binds to the wrong submitted bytes; they are outside the operational population and do not inflate its results.
Module example 3 / Grouping and destinations
A ride can create several reporting obligations.
- DEMO04 opens a claim grouping two services while preserving their individual components. A second example sends one leg to encounter and audit recipients, with distinct requirements and outcomes.
- Documented cancellations can also require reporting under one profile and be explicitly excluded under another. The requirement comes from the contract and source activity, rather than the existence of a claim header.
Three views support the same investigation: find the gap, inspect the record, then read the definition and checks.
Inspect the fixed snapshot counts and their populations
The demonstrated result
Construction, readiness and evidence are separate.
All six clients, full service period. Business horizon and knowledge cutoff: July 21, 2026, 23:59:59 UTC. Different populations and scopes; these rows are not a funnel.
| Demonstrated result | What it is | Why it matters |
|---|---|---|
| Claim construction28,035 of 28,040required preparation units constructed | A preparation unit is one required service component for a recipient and purpose. One ride may need both a base-service component and a mileage component. “Constructed” means the corresponding claim component exists, not that it is ready to send. | The expected work is defined independently of the claims that happened to be built. Incomplete construction stays visible in the population. |
| Encounter submission readiness21,356 of 24,040units ready for this target stage | Components with all required supported facts for encounter submission at the selected cutoffs. A component can exist but remain blocked, for example by missing vendor-payment evidence under the applicable synthetic profile. | A constructed claim can still lack a fact required for its next use. This row covers encounter targets only; the 4,000 audit-purpose units belong to the separate audit-readiness stage. |
| Outcome-evidence coverage9,158 of 28,040required reporting units with source-evidenced outcomes | Required component-and-recipient reporting obligations with an originating or supported forwarded decision. Both acceptance and rejection qualify as an evidenced outcome. | This includes supported acceptance and rejection. It shows where the outcome is evidenced, rather than an acceptance success rate. |
04 / Decisions the model makes possible
Explain what needs attention, and why.
Keep unfinished claims in the workload.
What: count expected work from the source service population, including components whose claim was never built.
Example: ten rides require twenty components. If two components are missing, the result is 18 of 20, not 18 of 18.
Why: the operations team can see the two missing components and investigate them. Excluding them would hide work and inflate completion.
Separate a missing fact from a later correction.
What: retain when the service happened and when supporting evidence became available.
Example: the billing identifier received July 16 cannot make the July 14 claim ready.
Why: a manager can distinguish a late evidence handoff from a team failing to use information it already had.
Find which handoff changed the facts.
What: compare source records → assembled claim → sent content as separate steps.
Illustration: the ride record says 4.11 miles. If the claim says 41.1, inspect claim construction. If the claim says 4.11 but the submission says 41.1, inspect submission mapping.
Why: the two errors need different owners and fixes. A recipient’s acceptance alone would not identify either one.
Send the follow-up to the right place.
What: preserve missing-payment evidence, missing responses and confirmed rejections as different conditions.
Example: seek a vendor-payment record from the payment-data handoff; seek a rejection explanation from the recipient’s response route.
Why: teams can investigate the actual dependency instead of repeatedly rebuilding a claim that is already supported.
The ten-ride and decimal-error examples illustrate the method; they are not additional measured results. Suggested follow-up is not evidence that outreach occurred.
05 / How the model supports those decisions
Follow one claim through the controls.
The same Cedar Harbor claim, from evidence to a decision
- 1
Source records
Ride details, member facts and the missing billing reference.
Scenario coverageKnown gaps and corrections exercise different paths.
- 2
Claim versions
Version 1 stays blocked. The later reference supports version 2.
Evidence rulesMissing facts stay missing; later information stays out of earlier decisions.
- 3
Readiness + sent record
Check version 2 for this target; preserve exactly what was sent.
Two comparisonsSource to claim; claim to submitted fields.
- 4
Recipient response
Bind the rejection to this delivery and version.
Evidence rulesDo not invent a rejection reason or treat acceptance as correctness.
- 5
Business view
Construction, readiness and outcome evidence remain separate.
RecalculationRecount from sources and compare the displayed values.
Controlled coverage: deliberately chosen cases test behavior; their frequency is not a real-world rate.
Conservative evidence: an unknown can remain unresolved rather than receiving a convenient assumed value.
Frozen release: repeatable comparisons are possible, but this is not a live operating feed.
Implementation details
This model preserves source records, claim versions, target requirements, submitted fields and response links in Python and JSON/JSONL. The browser presents a frozen analytical bundle using HTML, CSS, JavaScript and SVG.
The sent record is a synthetic payload, not a certified healthcare EDI transaction. EDI is the standard electronic exchange format used by many healthcare billing systems; transaction compliance is outside this build.
06 / Confidence and limits
Check the calculation and the meaning.
Published-value comparison
22,173 / 22,173
Numerical measure values matched a separate calculation.
Inspect the numerical comparison ↗These are values, not claims.
A published numerical cell is one measure value for a defined client filter, period, cutoff position and, where relevant, stage.
Example: 21,356 ready components at the full-scenario July 21 position is one value. The corresponding denominator, 24,040, is another. Counts for different clients and dates are separate values.
Business value: recounting them from the sources helps detect missing work, double counting or use of the wrong cutoff before a manager uses the dashboard to prioritize a queue. Agreement supports the calculation, not real-world savings or every modeling assumption.
Business rules were checked with known-answer examples.
- Missing is not zero: absent payment evidence must not become a recorded $0 payment or silently clear a required evidence hold.
- A correction has a date: the July 16 billing reference must not make the July 14 record ready.
- Accepted is not necessarily correct: compare the submitted fields with the supported claim even when a receiver accepts the message.
What was tested, and what does “152 checks pass” mean?
The recorded prepublication checklist contains 152 passing entries and 6 N/A dispositions. These are control and diagnostic observations, not 152 claims or a business success rate. N/A items are not counted as passes.
- Model checks: known-answer scenarios and deliberate faults test rules such as preventing duplicate effects and preserving earlier cutoffs.
- Presentation checks: recorded browser checks test filters, exact chart readouts and exports. They help the reader reach and inspect the intended records; they do not establish healthcare expertise or business impact.
- Examples of review fixes: missing vendor-payment evidence gained a concrete ledger example; unresolved responses gained a recipient-specific follow-up explanation. The review was simulated and restricted, not human user research.
Limits: all data is synthetic. Real-world savings, production adoption, independent evaluator custody and human usability research were not established. Scenario frequencies are not prevalence estimates.
Historical receipts retain their reviewed revisions. Current presentation checks cover this revision; they do not rerun historical analytical assurance.
07 / Next business questions
Test the next questions with better evidence.
The next iteration could test these four business questions. Real partner data would be needed to estimate how often the modeled problems occur.
Payment evidence
Which records would release the most blocked work?
- Decision
- Prioritize the payment-data handoff or another missing-data dependency.
- Why it matters
- If payment evidence clears many holds, obtaining that feed may be more useful than repeatedly rebuilding claims. Ready does not mean paid.
- Next experiment
- Add later payment evidence to matched scenarios and measure which components become ready, keeping other facts fixed.
Partner visibility
Is the service outcome missing, or just its response?
- Decision
- Improve the response feed or investigate actual rejected submissions.
- Why it matters
- A visibility problem needs better return evidence. A confirmed rejection needs the recipient’s explanation and an appropriate correction.
- Next experiment
- Vary response routes while holding the underlying synthetic decision fixed.
Work prioritization
Which follow-up should come first?
- Decision
- Assign limited staff time to the most urgent, actionable queue.
- Why it matters
- Deadline risk, dependency and expected effort can change which follow-up is worth doing first. A large queue alone does not establish priority.
- Next experiment
- Compare explicit deadline and effort assumptions, then validate response times before estimating benefits.
Operational realism
Would real partner data change the priority?
- Decision
- Choose which integration or process improvement deserves investment.
- Why it matters
- Deliberately balanced test cases cannot reveal which problems dominate an actual operation. Staffing or savings estimates need observed volumes and timing.
- Next experiment
- Calibrate the scenario mix with suitable partner data and compare the ranking of proposed improvements.
Future evaluation and operating capabilities are documented in Understand the data ↗.
These are proposed next steps, not additional completed results or new requirements for this frozen build.
Explore the build
Find the gap.
Follow the record.
Start with what prevents work from moving forward. Follow one example, then open the supporting facts when more detail is useful.
A synthetic portfolio demonstration. No actual payer submission, standards certification, measured revenue recovery or improvement in real-world acceptance is claimed.