RCM & insurance

Read authorization evidence and plan four distinct change intents

Follow wide list/detail controls and supported API plans while preserving requested/authorized separation, stable line identities and every unresolved external prerequisite.

18 min read · Source baseline f6e9f05f

Verification and applicability

Actual current root/Clinic read-only workbench, normal API four-plan200 and negative400 outcomes, independent unchanged-record verification

Check your installed version, permissions and local configuration.

Before you begin

This separate fictional draft and one unknown-adjudication line were initialized by IT using existing product test-factory conventions. No normal operator creation, real insurer response, actual approval, TAT obligation or external transaction is claimed.
Existing source-qualified configuration, approved transaction vocabulary, genuine payer evidence and exact package are prerequisites in real operation. This local fixture uses only an owned training URN and does not establish licensed external codes.

1. Find the request and open its exact evidence

Open Revenue Cycle → Authorizations, match the authorization number and choose Open. The current example is KB-FICTIONAL-AUTH-PLAN-001. Read effective state, clock, processing, adjudication, validity and recorded request time separately. Refresh only re-reads the server; it is not a submission or approval.

**Find the exact draft and keep status axes distinct · 2026-10-18**Recorded baseline screen · 1728 × 921
Capture details
Actual pinned MANSOQ local fictional Clinic, original wide Chrome capture. The actual list shows KB-FICTIONAL-AUTH-PLAN-001, no clock running, processing unknown, adjudication unknown, no stated validity and request time not recorded. Open leads to this exact draft. No approval, request submission or elapsed obligation exists.
**Exact draft identity**: Use the same request, not a similarly named case.
**No clock running**: No configured obligation can expire here.
**Processing unknown**: Different from adjudication.
**Adjudication unknown**: Not a denial or approval.
**Open**: Inspect line facts and evidence.
**Refresh**: Re-read current server context, without changing status.

2. Read requested and authorized line facts separately

Inspect the original stable sequence1: ownURN KB-CONSULT, requested2each on2026-10-18, with authorized quantity/amount/validity unknown and nothing authorized. Processing and adjudication are both unknown; no payer reference or response exists. A requested quantity is not an approved quantity, a missing approval is not a denial, and no patient cost share is permitted from this line.

**Inspect missing payer evidence, clock and authorized values · 2026-10-18**Recorded baseline screen · 1728 × 921
Capture details
Actual pinned MANSOQ local fictional Clinic, original wide Chrome capture. Actual detail preserves unknown processing/adjudication, no payer reference, no request/response time and no validity. No turnaround obligation is running. The ownURN consultation line requests2each but has no authorized code, quantity, amount or period. Unknown authorization does not permit cost sharing and is not patient debt.
**Processing unknown**: Never read complete processing as approval.
**No payer reference**: No real response exists.
**No obligation running**: No expiry, deemed approval or escalation is inferred.
**Requested2 each**: Requested values remain separate.
**Authorized quantity unknown**: Unknown is not0 or2approved.
**Cost share not permitted**: No patient liability is created.

3. Recognize when no turnaround obligation exists

No turnaround obligation is running in this actual detail. No period expires and no deemed approval or escalation can be inferred. Do not create a legal deadline or platform acknowledgement to make a fixture green. Clock observation/deeming require their own evidenced TAT rule, actual named clock, retained validated request, response/poll evidence, source/version and qualified package. Those positive external prerequisites were not established here.

4. Choose the exact intended mechanism through the supported API handoff

The current detail displays four informational intent cards and has no planning submit form. An authorized integration POSTs /api/v1/facility/{facilityId}/rcm/authorizations/{authorizationId}/amend/ with intent. The actual normal calls returned200 and posts_nothing=true for all four: amend_or_extend plans a new preauthorization related to the initial request with relationship prior; add_services_same_episode plans a new same-episode request/claim; correct_wrong_information requires cancel then fresh submission and forbids deletion; contest_decision plans communication referencing the original/latest authorization context. An HTTP200 plan does not execute any of these transactions.

**Read all four intents without inventing action controls · 2026-10-18**Recorded baseline screen · 1728 × 921
Capture details
Actual pinned MANSOQ local fictional Clinic, original wide Chrome capture. The actual read-only detail displays four intent cards: amend/extend, add services same episode, correct wrong information and contest decision. Cards list payload concepts but are not submit buttons. Normal API planning returned posts_nothing for each; original draft and sequence1 are unchanged. No external cancellation vocabulary, TAT authority, approval or transport was fabricated.
**Amend or extend**: New related preauthorization, initial request anchor.
**Add services same episode**: New request/claim with same episode identity, not overwrite.
**Correct wrong information**: Cancellation then fresh submission; no deletion.
**Contest decision**: Communication anchored to the latest authorization.
**Unknown line retained**: Planning does not change adjudication.
**Four mechanisms**: There is no generic resubmit operation.

5. Carry the complete snapshot with original sequences preserved

For an amendment the same endpoint may receive lines. The observed local plan carried source_sequence1 with quantity2/state established and added a new ownURN consultation line with quantity1/state established and no source sequence. It returned original sequence1 unchanged and new sequence2, with relationship prior. Serviced dates were omitted because neither line was completed; completed lines require their actual serviced dates. Independent DB still contains only original sequence1: proposed sequence2 is a plan, not a saved authorization line.

6. Investigate named intent, sequence and quantity refusals

Actual normal API requests refused400 when intent was resubmit, when source_sequence1 appeared twice, or when quantity2 was paired with quantity_state unknown. The system requires a known intent and sound value/state pairing. A malformed amendment is corrected as a new valid plan; it is not sent under a fresh identity to hide the original failure. Screenshots show actual read-only workbench context, not a claimed API-console error dialog.

7. Keep cancellation vocabulary and sufficiency prerequisites unresolved

POST /api/v1/facility/{facilityId}/rcm/authorizations/{authorizationId}/cancel/ with a deliberately fictional unqualified reason returned200, permitted=false and posts_nothing=true because the certified-package cancellation vocabulary was unresolved. No caller-supplied list was used to manufacture authority. The current /api/v1/facility/{facilityId}/rcm/authorizations/{authorizationId}/sufficiency/ endpoint refused400 config_package_required: this pinned view does not pass a config_package_id to the guarded engine. It also requires an operation-specific fix for typed dates/quantities and decision trace handling before successful production teaching. Preserve the refusal; do not remove the package guard.

8. Verify that planning changed no approval or transaction facts

Re-read the exact authorization and its lines/clocks after planning. Actual before/after API representations are identical; independent stored records retain draft, one requested2each sequence1, authorized unknown, no clock, no deemed approval and no claim. One automatic local eligibility validation_failed record was created during IT fixture initialization with sent_atNULL; no new exchange exists after initialization. No external request, cancellation, response, approval, adjudication, payment or legal authority is established by this exercise.

Source evidence

References are pinned to the private MANSOQ source repository. Repository access is required to open these links.