IT & integrations
Integrate eligibility interpretation, provenance and freshness without purpose promotion
Use exact request identity, typed scope, offline ownership and operation-specific readbacks; distinguish local interpreter results from real payer qualification.
16 min read · Source baseline f6e9f05f
Verification and applicability
Normal API verification201/freshness200/scope400/purpose400 and independent persisted-record/trace inspection, with exact current UI contexts
Check your installed version, permissions and local configuration.
Before you begin
- All observed inputs are expressly fictional and local. A new fictional patient/member was initialized by IT because the Enrollment surface has no operator-create path. Existing legacy cases, sources and25 qualification failures are unchanged.
- This demonstration uses existing explicitly synthetic policy/ranks/hooks/queues. Their unavailable source qualification remains a documented failure; executing the local interpreter does not establish real configuration qualification, insurance coverage or payer authority.
- Use an existing facility-authorized identity and the approved environment. Retain actual source bytes and original exchange identities in real operation; never paste credentials or clinical payloads into public examples.
1. Read the stored member and selected configuration context
GET /api/v1/facility/{facilityId}/rcm/enrollment/{coverageId}/eligibility/ returns coverage, latest_response, financial_clearance_context and the seven axes separately. The actual teaching member is9bfe03ed-3fd8-4c0c-b48a-c8bf9747c516. Its existing synthetic configuration can exercise local engines while its unavailable retained-source qualification remains failed. Readback is not a package go-live approval.
12345Capture 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.
- Policy unmapped: Do not invent a policy to clear the warning.
- Period unknown: No year or open-ended period is assumed.
- Unverified: Capture and verification are different states.
- Estimate restricted: The restriction limits financial assertions, not recording presented facts.
- Three purposes: Discovery, validation and benefit remain distinct.
123456Capture 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.
- Processing yes: Successful local interpretation is only one axis.
- Coverage unknown: Unknown is not not-eligible.
- Benefit unknown: The response contains no benefit lines.
- Clearance unknown: The latest response and immutable financial decision context are separate.
- Asked only: Purpose does not supply its own answer.
- Site outcome absent: Absence must not be inferred as eligible or not eligible.
2. Send an explicit original request identity and purpose scope
POST /api/v1/facility/{facilityId}/rcm/enrollment/{coverageId}/verify/ requires request_identifier, purposes, patient_identifiers with id_type/id_system/id_value, service_date and context. Validation/benefit additionally require coverage_ref or discovery_reference. The normal continuation used request_identifier KB-FICTIONAL-LOCAL-ELIGIBILITY-REQUEST-001, purposes[benefit], coverage_ref equal to the existing member ID and the owned training member namespace. A missing coverage/discovery reference refused400 eligibility_scope. A discovery request carrying benefit information refused400 purpose_promotion. No validator was changed. Screenshots show actual UI context/refusal, not an API console.
1234Capture 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.
- Exact refusal: Original request identity is required.
- Ordinary action: This click produced the refusal, not a saved result.
- Benefit scope: The API must also identify coverage/discovery at this purpose.
- Allowed channel needed: The local API continuation uses support_desk with explicit fictional provenance.
123456Capture 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.
- Processing yes: Successful local interpretation is only one axis.
- Coverage unknown: Unknown is not not-eligible.
- Benefit unknown: The response contains no benefit lines.
- Clearance unknown: The latest response and immutable financial decision context are separate.
- Asked only: Purpose does not supply its own answer.
- Site outcome absent: Absence must not be inferred as eligible or not eligible.
3. Record offline provenance as a named exception
The exercised response used requested_at2026-10-18T19:00Z, responded_at19:01Z, fictional reference FICTIONAL-LOCAL-RESPONSE-001-NO-PAYER, obtained_on2026-10-18, channel support_desk and obtained_by_ref for the existing actual training root. No real payer/support desk was contacted. The normal endpoint returned201, verification606e57a5-0b34-4608-985b-d16d0f3224b3 and guarantees_payment=false. The stored raw mock response remains pointed to by hash/reference in API output; no patient payload is published. UI currently omits original request, coverage scope and offline obtainer fields, so this is an explicit API continuation.
12345Capture 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.
- Site outcome absent: Catalogue entries are possible outcomes, not answers returned.
- Fictional reference: This is a local interpretation exercise, not a real insurer response.
- Channel and date: The saved offline exception has a named actual training actor in the independent record.
- No payment guarantee: A positive eligibility answer would still not guarantee payment.
- Processing column unknown: Do not silently replace the stored value state with the input string.
4. Verify persisted answers and do not claim generic idempotency
Independent DB has exactly one verification and one rule trace for this new member. Processing=yes and six unknown axes do not establish benefits or clearance; the separate processing_outcome value-state remains unknown. persist_verification appends records and only indexes request_identifier; repeated verify is not proven idempotent and may record a new response. After ambiguous timeout read the latest response, identity, timestamp, digest and trace before deciding whether another write is appropriate. Multiple legitimate responses may answer one original request; do not enforce uniqueness on request ID alone.
123456Capture 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.
- Processing yes: Successful local interpretation is only one axis.
- Coverage unknown: Unknown is not not-eligible.
- Benefit unknown: The response contains no benefit lines.
- Clearance unknown: The latest response and immutable financial decision context are separate.
- Asked only: Purpose does not supply its own answer.
- Site outcome absent: Absence must not be inferred as eligible or not eligible.
12345Capture 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.
- Site outcome absent: Catalogue entries are possible outcomes, not answers returned.
- Fictional reference: This is a local interpretation exercise, not a real insurer response.
- Channel and date: The saved offline exception has a named actual training actor in the independent record.
- No payment guarantee: A positive eligibility answer would still not guarantee payment.
- Processing column unknown: Do not silently replace the stored value state with the input string.
5. Evaluate freshness against the recorded policy and exact changed dimensions
POST /api/v1/facility/{facilityId}/rcm/enrollment/{coverageId}/freshness/ takes the current request, optional prior request, prior_responded_on and explicit as_of. The actual local tests returned200: same context age0 fresh=yes; service_date changed to2026-10-19 fresh=no/material_change_requires_recheck; as_of2026-11-18 yielded age31 and response_older_than_window. The30calendar-day window is explicitly a synthetic training policy, not a universal payer/regulator rule. These are computed API outcomes, not screenshot-proven UI controls or persisted approval.
123456Capture 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.
- Processing yes: Successful local interpretation is only one axis.
- Coverage unknown: Unknown is not not-eligible.
- Benefit unknown: The response contains no benefit lines.
- Clearance unknown: The latest response and immutable financial decision context are separate.
- Asked only: Purpose does not supply its own answer.
- Site outcome absent: Absence must not be inferred as eligible or not eligible.
6. Keep discovery, reconciliation and endorsement write boundaries explicit
discover/ and resolve-conflict/ return interpreted results; no persisted discovery/reconciliation business event is asserted. endorse/ resolves only existing scoped policy/class IDs, requires presented_evidence, preserves omitted period ends and runs full model validation before saving. This example’s normal UI saved only the existing synthetic policy/evidence after IT corrected the new fixture’s internal empty history. It retained class/program/network/period unknown. No source qualification, legal evidence, patient responsibility or external transaction was created.
1234Capture 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.
- Discovery only: No in-force or financial determination.
- Returned identity: 00001-KB-FICTIONAL is retained.
- Named queue key: The outcome names discovery_is_not_a_determination; it is not proof a work-item row was stored.
- Benefit still unusable: No cost share may be asserted.
1234Capture 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.
- Statements differ: Mismatch opens review, not default self-pay.
- Retained2, discarded0: Both original statements remain in the result.
- First retained statement: The differing card assertion is visible.
- Second retained statement: The differing letter assertion is visible.
123456Capture 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.
- Saved result: Independently verified in the member record.
- Class still unmapped: No complete class mapping claimed.
- Unverified retained: No coverage activation.
- Estimate restricted: Financial assertions remain limited.
- Exact stored policy: Only this policy reference changed.
- 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.
- repositories/platform/mansoq-web/src/pages/Facility/settings/rcm/coverage/EnrollmentDetail.tsx:110 · f6e9f05f
- repositories/platform/mansoq-web/src/pages/Facility/settings/rcm/coverage/EnrollmentDetail.tsx:548 · f6e9f05f
- repositories/platform/mansoq-web/src/pages/Facility/settings/rcm/coverage/EnrollmentDetail.tsx:710 · f6e9f05f
- repositories/platform/mansoq-web/src/pages/Facility/settings/rcm/coverage/EnrollmentDetail.tsx:1097 · f6e9f05f
- repositories/platform/mansoq-web/src/pages/Facility/settings/rcm/coverage/EnrollmentDetail.tsx:1254 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/eligibility.py:236 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/eligibility.py:436 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/eligibility.py:468 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/eligibility.py:571 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/eligibility.py:616 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/api/viewsets/rcm/eligibility.py:740 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/rcm/engines/eligibility.py:1507 · f6e9f05f
- repositories/platform/mansoq-core/mansoq/emr/rcm/engines/eligibility.py:2882 · f6e9f05f