Get insurance discovery search

Insurance Discovery APIs expose organization-scoped workflows for finding possible hidden coverage for self-pay or uninsured patients, reviewing local discovery search records, starting simulated batch discovery, retrying failed searches in simulated mode, and verifying or dismissing discovered coverage. The bearer API key selects the organization. Public request bodies should not be documented as tenant selectors, and `organizationId` in responses is ownership/context metadata rather than a caller-controlled organization switch. Patient, search, and batch identifiers must resolve inside the authenticated organization. Search inputs can include patient demographics and optional sensitive matching fields. Treat names, dates of birth, addresses, ZIP codes, Social Security number (SSN) last four digits, payer member IDs, discovered group IDs, and match details as Protected Health Information (PHI) or sensitive insurance data where applicable. Examples must stay synthetic, and public docs should discourage logging search terms, raw vendor payloads, Electronic Health Record (EHR) responses, credentials, tokens, storage keys, and payer portal data. The public surface has mixed side-effect profiles. List and get endpoints read local QuickRCM Revenue Cycle Management (RCM) discovery records. `verifyDiscoveredCoverage` performs local database updates and is documented with `SAFE_WRITE_DB_ONLY` metadata. `startInsuranceDiscoveryBatch` and `retryInsuranceDiscoverySearch` require `simulateOnly: true` and return `SIMULATED_ONLY` metadata because those workflows can consume credits and call the simulated discovery vendor. Retry requests do not accept replacement demographics; current retry behavior reuses the failed search's stored first name, last name, date of birth, address, and ZIP code while not resubmitting stored SSN last-four. `runInsuranceDiscoverySearch` has no public `simulateOnly` flag; it can create a local PHI-bearing search record, consume discovery credits, and potentially transmit patient demographics to a discovery vendor, so document it with credit and privacy warnings. Verification should be described as a local QuickRCM coverage/account state update, not payer adjudication, eligibility verification, claim readiness, or EHR insurance write-back. Existing module docs state that direct EHR write-back is not wired from Insurance Discovery. Current public verification evidence supports creating a new local `PatientInsurance` record when discovered member data is available and storing that new identifier on the search; otherwise `patientInsuranceId` remains null. Downstream eligibility re-verification, claim use, payer configuration resolution, and optional EHR synchronization require separate workflows.

The route class, authentication state, tenancy rule, side-effect mode, idempotency status, async behavior, file policy, warnings, links, and evidence above are part of the endpoint contract. Treat generated examples below as internal baseline aids until release evidence closes.