RCM & insurance
Handle denial payload, replay and unsupported-linkage refusals
Use the supported remedy contract, diagnose real refusals and confirm retry outcomes without duplicate history or invented external authority.
12 min read · Source baseline f6e9f05f
Verification and applicability
Actual wide root/Clinic UI writes for all four remedies, independent database and normal API detail/replay checks
Check your installed version, permissions and local configuration.
Before you begin
- Read the four-remedy walkthrough and identify the exact facility-scoped denial before any retry. All API results below came from the current ordinary local backend.
1. Use the exact remedy and payload, not a generic resubmit
An authorized integration POSTs /api/v1/facility/{facilityId}/rcm/denials/{denialId}/remedy/. remedy is exactly correction, information_response, reconsideration or appeal. Actual resubmit returned400 unknown_remedy. Correction requires cancellation_reason_code, corrected_fields and rationale; information_response requires requested_items, attachments and narrative; reconsideration requires contested_lines, justification and attachments; appeal requires justification, attachments and reviewer_challenge. Actual incomplete appeal returned400 remedy_payload_incomplete listing missing attachments/reviewer_challenge. The wide images show real form context; these API refusals were preserved in JSON, not fabricated as UI dialogs.
123456Capture details
Actual original wide Chrome capture; fictional local Clinic recordkeeping. The actual correction and information-response cards start disabled with separate required payloads. This local recordkeeping endpoint does not perform the transaction mechanisms printed on the cards.
- Correction card: Distinct clinical/coding record.
- Information card: Separate response payload.
- Cancellation reason: Actual transactions need certified vocabulary separately; this exercise supplies none.
- Corrected fields: One field per line.
- Attachment references: References only, no file-upload validation here.
- Disabled until complete: Complete each card’s required fields.
123456Capture details
Actual original wide Chrome capture; fictional local Clinic recordkeeping. The contested case exposes exactly reconsideration and appeal, with distinct payloads and the explicit unpublished claim-item-sequence extension guard. Both are claim-level local history records; no actual payer rejection or qualified reviewer is represented.
- Reconsideration: Contested lines, justification and references.
- Appeal: Justification, references and reviewer challenge.
- Line linkage blocked: Do not invent an unpublished extension.
- Contested lines: Content references do not change claim-level wire scope.
- Reviewer challenge: Requires truthful supported facts in real use.
- Incomplete appeal disabled: Each payload must be complete.
2. Keep claim-level scope and unresolved authority intact
Actual appeal with claim_line returned400 line_level_remedy_unavailable, blocked_by claim_item_sequence_extension_not_published. Existing line references inside a reconsideration payload identify contested content; they do not publish an extension. Actual route-dispute with an unrecognized subject returned400 dispute_subject_unrouted. No real authority filing, complaint, reviewer qualification or certified cancellation set was created. The visible routing catalogue is product context; a local route/history record would not prove external delivery or legal jurisdiction for a real case.
123456Capture details
Actual original wide Chrome capture; fictional local Clinic recordkeeping. The contested case exposes exactly reconsideration and appeal, with distinct payloads and the explicit unpublished claim-item-sequence extension guard. Both are claim-level local history records; no actual payer rejection or qualified reviewer is represented.
- Reconsideration: Contested lines, justification and references.
- Appeal: Justification, references and reviewer challenge.
- Line linkage blocked: Do not invent an unpublished extension.
- Contested lines: Content references do not change claim-level wire scope.
- Reviewer challenge: Requires truthful supported facts in real use.
- Incomplete appeal disabled: Each payload must be complete.
3. Read back an ambiguous result before retrying
GET the exact facility-scoped denial and inspect remedy_history.all plus its separate track arrays. Our actual normal API replayed the exact last UI payload without request_key and returned200/replayed=true for information_response and appeal; history stayed exactly2 per denial. Without a key, only the last identical remedy/payload deduplicates. Source also supports caller request_key or Idempotency-Key: same key and same payload returns the retained entry; same key with changed remedy/payload refuses400 remedy_request_key_reused. Keyed behavior is source-defined here and was not separately posted in this rehearsal. Do not send a fresh key merely to hide an unknown outcome.
12345Capture details
Actual original wide Chrome capture; fictional local Clinic recordkeeping. Actual history now shows correction and information response as two separate clinical/coding entries, with contested and financial concession counts still0. The normal response toast says recorded; independent DB verifies retained content, actor and timestamp.
- Clinical/coding count2: Both entries persist.
- Original correction retained: No overwrite.
- Information response retained: Separate timestamped record.
- Concessions0: No financial movement.
- Recorded toast: Corroborated by independent record readback.
1234Capture details
Actual original wide Chrome capture; fictional local Clinic recordkeeping. Actual contested history retains reconsideration and appeal as two distinct timestamped entries. Independent database readback confirms both payloads and actor/time; claims remain drafts with submitted_at NULL and no new exchange or financial concession.
- Contested count2: Two separate remedies saved.
- Reconsideration retained: No overwrite.
- Appeal retained: Separate exact action.
- Concessions0: No recovery or financial write.
4. Distinguish retained evidence from business qualification
The owned two-entry PDF was uploaded through Source Evidence, separately content-reviewed by an existing Clinic administrator, then actual retained bytes re-read and SHA256 matched against the authored PDF. IT initialized two distinct inferred-evidence local maps with no approved_by, approved_at or published_at; responsibility remains undetermined. This proves local recordkeeping rehearsal, not normal operator map activation, source-backed contractual allocation, product legal qualification or external readiness. Preserve the legacy unreadable source failures and all production approval/publication gates.
123456Capture details
Actual original wide Chrome capture; fictional local Clinic recordkeeping. Two visibly fictional ownURN cases expose different remedy pairs. Both remain open, financial responsibility undetermined and patient debt undecided. All four denial desks are currently not configured; this rehearsal does not claim completed queue governance.
- Exact reason: Do not infer financial responsibility from a denial reason.
- Undetermined: No patient or payer debt established.
- Contested remedy pair: Reconsideration and appeal are distinct.
- Correction remedy pair: Correction and information response are distinct.
- Work it: Open the exact contested case.
- Desk not configured: Map owner is not proof queue governance exists.
Source evidence
References are pinned to the private MANSOQ source repository. Repository access is required to open these links.
- repositories/platform/mansoq-web/src/pages/Facility/revenueCycle/DenialWorkbenchPage.tsx:172 · f6e9f05f
- repositories/platform/mansoq-web/src/pages/Facility/revenueCycle/DenialWorkbenchDetailPage.tsx:212 · f6e9f05f
- repositories/platform/mansoq-web/src/pages/Facility/revenueCycle/DenialWorkbenchDetailPage.tsx:528 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/claims_serializers.py:46 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/claims_serializers.py:558 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/claims.py:257 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/claims.py:376 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/models/rcm/completeness.py:311 · f6e9f05f