MANSOQ Knowledge
← Knowledge library

RCM & insurance

Discover coverage, interpret separate answers and preserve unresolved enrollment facts

Use exact wide enrollment controls for discovery, current refusal, saved local interpretation, conflicting evidence and partial mapping without turning unknown information into insurance clearance.

20 min read · Source baseline f6e9f05f

Verification and applicability

Exact current root/Polyclinic UI discovery, conflict and endorsement observations; normal scoped verification/freshness APIs and independent database readbacks

Check your installed version, permissions and local configuration.

Before you begin

1. Identify the provisional member and every unknown fact

Open Settings → Enrollment and select the intended member. Match patient/beneficiary/subscriber roles and status separately. This distinct training member starts with no policy, class, network, program or coverage period. The estimate restriction limits what may be asserted financially; it does not require fabricating a year or policy to record what was presented.

The new fictional member begins unverified with policy/class/network/program unmapped and coverage period unknown. Registration evidence exists, but the estimate is restricted and no payer response is recorded. Unknown period is not an open-ended window or a fabricated year.12345
Read provisional enrollment without inventing missing configuration · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. The new fictional member begins unverified with policy/class/network/program unmapped and coverage period unknown. Registration evidence exists, but the estimate is restricted and no payer response is recorded. Unknown period is not an open-ended window or a fabricated year.

  1. Policy unmapped: Do not invent a policy to clear the warning.
  2. Period unknown: No year or open-ended period is assumed.
  3. Unverified: Capture and verification are different states.
  4. Estimate restricted: The restriction limits financial assertions, not recording presented facts.
  5. Three purposes: Discovery, validation and benefit remain distinct.

2. Record discovery at the configured channel scope

Choose Discover, identify the channel from the installed discovery ladder, enter presented identities and a clear note, then Record discovery. In this mock ladder rank4 means member_card_or_policy_number; the current selector displays ranks only, so do not assume4 means the same in every facility. The normal result is Discovery only and discovery_is_not_a_determination. This service returns an outcome and named queue key; it does not persist a payer response or make a financial determination. The full result capture was taken later after partial policy mapping.

Actual Discover tab: configured rank4 is member_card_or_policy_number in this local ladder, not a universal rank. The operator entered00001-KB-FICTIONAL and an explicit no-payer/no-clearance note, then selected Record discovery. A card is input, not an in-force or benefit determination.1234
Prepare member-card discovery with an explicit fictional note · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Actual Discover tab: configured rank4 is member_card_or_policy_number in this local ladder, not a universal rank. The operator entered00001-KB-FICTIONAL and an explicit no-payer/no-clearance note, then selected Record discovery. A card is input, not an in-force or benefit determination.

  1. Configured channel rank4: Read the installed discovery ladder; rank alone does not name a universal channel.
  2. Presented member identity: Preserve leading zeros and identifier context.
  3. Fictional note: No actual payer response is asserted.
  4. Record discovery: This operation computes a discovery outcome; it does not activate coverage.
Actual normal discovery result shows Discovery only, returned fictional member identity and discovery_is_not_a_determination. The later full-result capture follows partial policy mapping, while class/program/network/period and usable benefit remain unresolved. The service returns a result; no persisted discovery event or payer determination is claimed.1234
Read Discovery only and retain its scope · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Actual normal discovery result shows Discovery only, returned fictional member identity and discovery_is_not_a_determination. The later full-result capture follows partial policy mapping, while class/program/network/period and usable benefit remain unresolved. The service returns a result; no persisted discovery event or payer determination is claimed.

  1. Discovery only: No in-force or financial determination.
  2. Returned identity: 00001-KB-FICTIONAL is retained.
  3. Named queue key: The outcome names discovery_is_not_a_determination; it is not proof a work-item row was stored.
  4. Benefit still unusable: No cost share may be asserted.

3. Distinguish the purposes asked from the answers actually supplied

Discovery identifies known coverages, validation asks whether a coverage is in force on a service date, and benefit asks for plan details. On Verify, selecting Benefit only marks seven axes in scope; it does not answer them. Preserve identifier type, system and leading-zero value, service date and separate response timestamp. Leave site eligibility absent if it was not stated.

Current Verify form shows Benefit selected, seven axes in scope, actual service-date/identifier namespace fields and offline reference/date/channel. It lacks original request identifier and coverage/discovery-reference fields. The displayed fictional channel string is intentionally not an operational enum; use only the documented API payer_portal/support_desk values with retained real evidence in actual operation. This frame is prepared input, not stored verification.12345
Inspect purpose scope and structured provenance before recording · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Current Verify form shows Benefit selected, seven axes in scope, actual service-date/identifier namespace fields and offline reference/date/channel. It lacks original request identifier and coverage/discovery-reference fields. The displayed fictional channel string is intentionally not an operational enum; use only the documented API payer_portal/support_desk values with retained real evidence in actual operation. This frame is prepared input, not stored verification.

  1. Purpose asked: In scope is not the same as answered.
  2. Service date: Business date is distinct from response timestamp.
  3. Identifier namespace: Type, system and value are separate.
  4. Offline exception: Needs reference, date, allowed channel and named obtainer.
  5. Fictional free text: Do not copy this deliberately fictional channel into an operational request.

4. Recognize the current form limitation and use an authorized API handoff

The actual Record response attempt refused a request records its own identifier. This pinned form omitted request_identifier and coverage/discovery references. Offline interpretation also requires a permitted payer_portal/support_desk channel and named obtained_by_ref; the screenshot’s intentionally fictional free text must not be copied as an operational channel. The companion integration guide uses the supported normal API with explicit retained identifiers and structured fictional provenance. Do not mark the refused form as saved or widen any validator.

Normal UI Record response refused with the visible message a request records its own identifier (ch.22). The current form did not send request_identifier. No verification was stored by this failed action. Benefit/validation also require coverage_ref or discovery_reference; offline interpretation requires an allowed channel and obtained_by_ref. Supported API continuation supplied the exact missing fields without weakening any engine check.1234
Recognize the missing original-request identity refusal · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Normal UI Record response refused with the visible message a request records its own identifier (ch.22). The current form did not send request_identifier. No verification was stored by this failed action. Benefit/validation also require coverage_ref or discovery_reference; offline interpretation requires an allowed channel and obtained_by_ref. Supported API continuation supplied the exact missing fields without weakening any engine check.

  1. Exact refusal: Original request identity is required.
  2. Ordinary action: This click produced the refusal, not a saved result.
  3. Benefit scope: The API must also identify coverage/discovery at this purpose.
  4. Allowed channel needed: The local API continuation uses support_desk with explicit fictional provenance.

5. Compare the persisted latest response against financial-clearance context

After the normal local API stored one interpretation, reload Eligibility. Processing succeeded is Yes; coverage, site/network, benefits, exclusions, cost share and authorization requirements remain Unknown. Financial-clearance context remains Unknown in all seven axes because no clearance decision was made. Benefit Asked does not turn missing benefit lines into supplied benefits. Mapping warnings and unusable-benefit restriction remain.

Independent stored-record readback confirms processing=yes and all six other latest-response axes unknown. Every financial-clearance-context axis remains unknown because no clearance decision exists. Benefit Asked means the question was asked; it does not establish returned benefits. The source response is expressly fictional and no external payer answered.123456
Compare latest response against financial-clearance context · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Independent stored-record readback confirms processing=yes and all six other latest-response axes unknown. Every financial-clearance-context axis remains unknown because no clearance decision exists. Benefit Asked means the question was asked; it does not establish returned benefits. The source response is expressly fictional and no external payer answered.

  1. Processing yes: Successful local interpretation is only one axis.
  2. Coverage unknown: Unknown is not not-eligible.
  3. Benefit unknown: The response contains no benefit lines.
  4. Clearance unknown: The latest response and immutable financial decision context are separate.
  5. Asked only: Purpose does not supply its own answer.
  6. Site outcome absent: Absence must not be inferred as eligible or not eligible.
After supported normal API interpretation, the actual UI still shows unverified, all five mapping/period warnings and benefit_answer_not_usable. The local fictional response stored processing=yes with six unknown axes and no clearance; it did not fabricate a policy, class, amount or coverage date.123
Confirm that a stored interpretation does not complete mapping · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. After supported normal API interpretation, the actual UI still shows unverified, all five mapping/period warnings and benefit_answer_not_usable. The local fictional response stored processing=yes with six unknown axes and no clearance; it did not fabricate a policy, class, amount or coverage date.

  1. Still unverified: A stored interpretation is not coverage activation.
  2. Mapping remains incomplete: No omitted references are auto-created.
  3. Benefit unusable: Do not assert cost share from this response.

6. Inspect provenance, absence and residual risks

Read the separately saved offline reference, allowed channel, obtained date and named actor. The explicit reference says FICTIONAL-LOCAL...NO-PAYER. The actual UI processing-outcome column remains unknown in this release, even though its processing answer axis is Yes; do not silently promote the input string to a stored value. Site catalogue entries remain not stated, Guarantees payment is No, and service-before-effective-date, member mismatch and missing preauthorization risks remain separate.

Actual saved UI has no stated site outcome, a FICTIONAL-LOCAL-RESPONSE-001-NO-PAYER offline reference, support_desk date2026-10-18 and Guarantees payment No. The separate persisted processing_outcome column remains unknown in this release even though the answer-axis processing=yes. Residual risks remain named; no real payer evidence is claimed.12345
Read absent site outcome, fictional provenance and no payment guarantee · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Actual saved UI has no stated site outcome, a FICTIONAL-LOCAL-RESPONSE-001-NO-PAYER offline reference, support_desk date2026-10-18 and Guarantees payment No. The separate persisted processing_outcome column remains unknown in this release even though the answer-axis processing=yes. Residual risks remain named; no real payer evidence is claimed.

  1. Site outcome absent: Catalogue entries are possible outcomes, not answers returned.
  2. Fictional reference: This is a local interpretation exercise, not a real insurer response.
  3. Channel and date: The saved offline exception has a named actual training actor in the independent record.
  4. No payment guarantee: A positive eligibility answer would still not guarantee payment.
  5. Processing column unknown: Do not silently replace the stored value state with the input string.

7. Reconcile exactly two presented statements and retain both

Open Resolve conflicts. Enter each kind, presented value, date and presenter, then Reconcile. The two fictional inputs disagree about class and explicitly disclaim actual policy/employer evidence. The result says2 statements retained and0 discarded. This endpoint returns a reconciliation result; it does not append those two statements to stored member evidence, select a legal winner, create a class or make an estimate certain. Retain real source records through their supported evidence workflow in actual operation.

Actual Resolve conflicts form takes two fictional statement kinds, values, presented dates and presenters. Each explicitly says no actual policy/employer. Reconcile compares the statements without inventing policy/class or assigning patient liability.12345
Enter exactly two complete presented statements · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Actual Resolve conflicts form takes two fictional statement kinds, values, presented dates and presenters. Each explicitly says no actual policy/employer. Reconcile compares the statements without inventing policy/class or assigning patient liability.

  1. First statement kind: Retain its origin instead of only the disputed value.
  2. First value: Clearly fictional classA assertion.
  3. Presented date: Both example statements are dated2026-10-18.
  4. Second presenter: Retain who presented each statement.
  5. Reconcile: Result interpretation is separate from persisted configuration changes.
Actual normal UI result says The statements differ,2 statements retained and0 discarded, with both fictional inputs listed. This endpoint returns reconciliation; it does not write the two statements into the member evidence list, select a winning legal contract, create a policy/class or establish financial clearance.1234
Keep both conflicting statements and discard neither · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Actual normal UI result says The statements differ,2 statements retained and0 discarded, with both fictional inputs listed. This endpoint returns reconciliation; it does not write the two statements into the member evidence list, select a winning legal contract, create a policy/class or establish financial clearance.

  1. Statements differ: Mismatch opens review, not default self-pay.
  2. Retained2, discarded0: Both original statements remain in the result.
  3. First retained statement: The differing card assertion is visible.
  4. Second retained statement: The differing letter assertion is visible.

8. Investigate the refused endorsement before retrying

The first partial Endorse attempt reached a400 history field validation and the current nested-error renderer crashed. Independent stored-record inspection proved policy and evidence were unchanged. IT completed only the new fixture’s internal origin history metadata; no business authority or unknown configuration was supplied. A normal user should retain the error and seek the supported installation fix; this private sandbox metadata initialization is not an operator recovery procedure.

The first normal UI partial endorsement received400 because the IT fixture had the base model default empty history; the nested error renderer then crashed. Normal API diagnostic retained errors.msg.detail.history This field cannot be blank, and independent DB proved no mapping/evidence write. This screenshot shows only the actual generic failure page, not the hidden API reason.1
Preserve the actual refused-endorsement error page · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. The first normal UI partial endorsement received400 because the IT fixture had the base model default empty history; the nested error renderer then crashed. Normal API diagnostic retained errors.msg.detail.history This field cannot be blank, and independent DB proved no mapping/evidence write. This screenshot shows only the actual generic failure page, not the hidden API reason.

  1. Actual error page: Save context and independently inspect the refused request before retrying; do not assume success.

9. Map only a known stored policy with the evidence actually available

On Endorse select the existing policy and an applicable configured class when it exists; this local policy had no policy-scoped class choice available, so class was left unknown. Enter presented evidence kind, value and date. The actual retry selected000-KB-SYNTHETIC-2026 with an explicit fictional-only statement and2026-10-18 date, leaving both coverage dates blank. Do not manufacture a class or period merely to finish a form. Choose Endorse and independently re-read the saved member.

After IT completed only the fixture-origin history metadata, the ordinary Endorse form selects the pre-existing000-KB-SYNTHETIC-2026 policy and explicit fictional evidence/date. Class and both coverage dates remain blank. No new policy/class is created and no missing financial or external evidence is supplied by the metadata repair.12345
Map only the stored known synthetic policy and preserve unknown dates · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. After IT completed only the fixture-origin history metadata, the ordinary Endorse form selects the pre-existing000-KB-SYNTHETIC-2026 policy and explicit fictional evidence/date. Class and both coverage dates remain blank. No new policy/class is created and no missing financial or external evidence is supplied by the metadata repair.

  1. Stored synthetic policy: Leading zeros preserved; not an actual approved insurer contract.
  2. Class not selected: No policy-specific class choice was available; do not invent one.
  3. Coverage dates absent: Unknown remains unknown.
  4. Explicit fictional input: A declared teaching input, not actual coverage proof.
  5. Endorse: Saves only supplied known references/evidence.

10. Verify exactly what the partial mapping changed

Endorsement recorded removes only Policy unmapped. Independent DB confirms one existing synthetic policy reference and one appended presented-evidence entry. Class/network/program/period remain unknown, status unverified and benefit answer unusable. The existing source qualification failures remain. This saved partial mapping establishes neither real insurance, payer response, financial clearance nor actual legal/source authority.

Actual normal UI shows Endorsement recorded and removes only Policy unmapped. Independent DB confirms the pre-existing synthetic policy ID and one appended fictional evidence entry. Class/program/network/period remain unknown; status unverified and benefit answer unusable remain. The internal origin history completion did not alter any source, approval, package, authority, eligibility answer or business validator.123456
Verify the saved partial policy mapping and remaining restrictions · 2026-10-18Recorded baseline screen · 1728 × 921
Capture details

Actual pinned MANSOQ frontend, isolated fictional Polyclinic, original wide Chrome1728×921. Actual normal UI shows Endorsement recorded and removes only Policy unmapped. Independent DB confirms the pre-existing synthetic policy ID and one appended fictional evidence entry. Class/program/network/period remain unknown; status unverified and benefit answer unusable remain. The internal origin history completion did not alter any source, approval, package, authority, eligibility answer or business validator.

  1. Saved result: Independently verified in the member record.
  2. Class still unmapped: No complete class mapping claimed.
  3. Unverified retained: No coverage activation.
  4. Estimate restricted: Financial assertions remain limited.
  5. Exact stored policy: Only this policy reference changed.
  6. No period invented: Dates remain absent in the database.

Source evidence

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