Every API here is available over the APIs.io API and to AI agents over MCP.
openapi: 3.2.0
info:
title: Enhanced Eligibility Coverage Discovery API
description: 'Enhanced Eligibility provides real-time eligibility verification for medical benefit inquiries and optional Coverage Discovery workflows when additional coverage needs to be researched asynchronously.
Timing guidance:
- Real-Time Eligibility is synchronous, but payer and clearinghouse response time dominate the end-to-end latency.
- The OI Enterprise gateway times out at 110 seconds for this API.
- Request deduplication is customer-configurable and determines whether a request is sent to the clearinghouse or short-circuited by replaying a prior transaction response.
- RTCOB and Coverage Insight also use a separate non-configurable 72-hour request cache. When that cache is hit, the path is marked as skipped instead of creating a new downstream submission.
- Coverage Discovery is asynchronous because some paths involve chained clearinghouse work and additional connected workflow dependencies.
- Most non-Coverage-Insight discovery paths are near real time relative to traditional discovery workflows.
- Customers with strict turnaround sensitivity should evaluate Coverage Insight enrollment carefully.
- Coverage Discovery paths and add-ons are enabled per customer and are not included automatically.
Primary integration patterns:
1. Submit a real-time eligibility request as normalized JSON or as a JSON request body with `x12` set to the X12 270 payload, and receive a normalized JSON response.
2. If enrolled in Coverage Discovery, inspect the real-time response `link` header for related discovery task resources when discovery is automatically triggered from the real-time request/response.
3. For advanced use cases, submit Coverage Discovery requests directly when you already possess a processed canonical eligibility request and, when needed, a processed eligibility response, and want asynchronous follow-up processing using a callback URL or by polling the discovery task resource.
4. When using direct discovery, the X12 workflow is often easier than the canonical JSON workflow because it accepts the processed `x12-270` and `x12-271` rather than requiring mapping into both canonical models.
'
version: v0.2.0
servers:
- url: https://sandbox-apigw.optum.com
description: Sandbox server (uses test data)
- url: https://apigw.optum.com
description: Production server (uses live data)
tags:
- name: Coverage Discovery
description: 'Create and retrieve asynchronous Coverage Discovery tasks. Coverage Discovery paths and add-ons are enabled per customer and are not included automatically. These endpoints support direct submission using either normalized eligibility data or JSON bodies containing X12 payloads, dry-run validation of enrolled discovery paths, polling for task status, and callback-based delivery of completed discovery results.
'
paths:
/rcm/eligibility/v1/coverage-discovery:
post:
operationId: postDiscovery
tags:
- Coverage Discovery
summary: Submit new discovery task(s)
security:
- oAuth:
- create_coveragediscovery
description: "\n## Overview\n\n__You must be enrolled in the Coverage Discovery feature in order to use this system.__\n\nCoverage Discovery paths and add-ons are enabled per customer and are not included automatically.\n\nCoverage Discovery is an async process that initializes discovery paths based on the task(s) enabled for the customer and on the details of the provided `canonicalEligibilityRequest` and, when available, `canonicalEligibilityResponse`. `canonicalEligibilityRequest` is always required. `canonicalEligibilityResponse` is optional for request-only qualification paths, but should be supplied when path qualification or request-building depends on response-side facts such as response status, payer context, HMO plan information, or Medicare QMB/MBI data. This direct JSON workflow is intended for advanced use cases where the client already has the processed canonical eligibility models available. If successful, the initial response is either a 202 Accepted receipt for a single record or a 207 Multi-Status response if more than one record was produced from the request and the customer has more than one enabled task.\n\nCoverage Discovery is asynchronous because some paths involve chained clearinghouse work and additional connected workflow dependencies. Most non-Coverage-Insight paths are near real time relative to traditional discovery workflows. Customers with strict turnaround sensitivity should evaluate Coverage Insight enrollment carefully.\nCoverage Discovery paths may also participate in customer-configured deduplication. This can be enabled per path rather than uniformly across every path. RTCOB and Coverage Insight additionally use a separate non-configurable 72-hour request cache. When that cache is hit, the path is added to `discoveryPaths.skipped` instead of creating a new downstream submission.\nTo test if the request meets conditions to generate tasks, see the Dry Run section. \n\nSupported task types are `serial` and `chained`. In `serial` tasks, multiple qualified paths may be initialized under the same task. In `chained` tasks, later paths may depend on the outcome of earlier paths.\n\n## Async Delivery Flow\n\n1. Submit the Coverage Discovery request.\n2. If `dryRun` is `false`, the API accepts work for asynchronous processing.\n3. For single-task execution, a `202 Accepted` response includes a `location` header for the created discovery task resource.\n4. For multi-task execution, a `207 Multi-Status` response returns per-task results, and accepted items include an `href` for each created task resource.\n5. If you provide `callbackUrl`, your callback endpoint later receives the completed task payload asynchronously.\n6. If needed, you can poll `/coverage-discovery/{id}` using the task resource returned in `location` or `href`.\n\n## Dry Run\nTo validate that your request meets expected conditions for the paths enabled for your customer, include `dryRun = true` in the request body. In dry-run mode, the request does not execute discovery, does not create task records, and does not send a callback. Instead, the endpoint validates the request against the enrolled discovery paths. The response indicates which paths qualified and which did not.\n\nIf successful, the first response is a receipt with either a 200 status for a single task or 207 if the request produced more than one per-task outcome. If no paths qualify, a 422 will be returned for a single task, and a 207 for multi-task responses that include one or more 422 results (see `DryRunMultiStatusMixedResponse` example).\n\n### Callback API\nDue to the long-running nature of the discovery process, completed task responses can be communicated asynchronously to `request.callbackUrl` when `callbackUrl` is supplied. `callbackUrl` is optional on standalone Coverage Discovery request bodies, including when `dryRun` is `true`. If `callbackUrl` is omitted, use the task resource returned in `location` or `href` to poll for completion. If this is your first time using callbacks via Swagger, check out the __\"Callbacks\"__ tab next to __\"Parameters\"__.\n\nWhen supplied, the API specified in the `callbackUrl` that will receive the asynchronous response once discovery finishes must meet the customer-specific whitelisting requirements defined by your team. Please reach out to support if you need to configure whitelisting. This API must meet the callback structure documented in the \"CustomerCallbacks\" tab.\n\nYour callback implementation should treat deliveries as asynchronous webhook-style notifications and should be prepared to process the same task idempotently if a delivery is retried. The callback payload uses the same `CoverageDiscoveryTask` model returned by `GET /coverage-discovery/{id}`. The most important fields for most clients are the task `id`, task `status`, any error or failure details, and the embedded real-time eligibility content when callback consolidation is enabled.\n\nIf you are unsure about the details of your request and how they might produce eligible discovery paths, you can use `dryRun` to test the request without executing any transactions. When `dryRun` is enabled, the response is synchronous and the callback is not invoked.\n"
parameters:
- $ref: '#/components/parameters/header-correlation-id'
- $ref: '#/components/parameters/header-subtenant-id'
requestBody:
$ref: '#/components/requestBodies/DiscoveryRequest'
callbacks:
response:
'{$request.body#/callbackUrl}':
post:
parameters:
- $ref: '#/components/parameters/header-tenant-id'
- $ref: '#/components/parameters/header-correlation-id'
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CoverageDiscoveryTask'
examples:
Successful Serial Task:
$ref: '#/components/examples/GetCoverageDiscoveryTaskSerialSuccess'
Successful Serial Task With Real Time Response:
$ref: '#/components/examples/GetCoverageDiscoveryTaskSerialSuccessRealTime'
Successful Chained Task:
$ref: '#/components/examples/GetCoverageDiscoveryTaskChainedSuccess'
Failure Serial Task:
$ref: '#/components/examples/GetCoverageDiscoveryTaskSerialFailure'
Failure Serial Task With Real Time Response:
$ref: '#/components/examples/GetCoverageDiscoveryTaskSerialFailureRealTime'
Failure Chained Task:
$ref: '#/components/examples/GetCoverageDiscoveryTaskChainedFailure'
responses:
'204':
description: Return `204 No Content` after successfully accepting and processing the callback payload.
responses:
'200':
$ref: '#/components/responses/DiscoveryDryRunResponse'
'202':
$ref: '#/components/responses/DiscoveryAcceptedResponse'
'207':
$ref: '#/components/responses/DiscoveryMultiStatusResponse'
'400':
$ref: '#/components/responses/BadRequestError'
'401':
$ref: '#/components/responses/PermissionDeniedError'
'403':
$ref: '#/components/responses/ForbiddenError'
'422':
$ref: '#/components/responses/UnprocessableEntityDiscoveryError'
5XX:
$ref: '#/components/responses/UnexpectedError'
get:
operationId: getAllDiscoveries
tags:
- Coverage Discovery
summary: Find all discovery tasks
security:
- oAuth:
- read_coveragediscovery
description: 'Retrieves discovery tasks based on the supplied query parameters. When no parameters are provided, the endpoint returns the full set of discovery tasks, delivered in paginated form.
'
parameters:
- $ref: '#/components/parameters/header-correlation-id'
- $ref: '#/components/parameters/query-correlationid'
- $ref: '#/components/parameters/query-task-status'
- $ref: '#/components/parameters/query-start-date-time'
- $ref: '#/components/parameters/query-end-date-time'
- $ref: '#/components/parameters/query-sort-discovery'
- $ref: '#/components/parameters/query-offset'
- $ref: '#/components/parameters/query-limit'
responses:
'200':
description: OK
headers:
x-optum-tenant-id:
$ref: '#/components/headers/tenantid'
x-optum-correlation-id:
$ref: '#/components/headers/correlationid'
x-optum-trace-id:
$ref: '#/components/headers/traceid'
link:
$ref: '#/components/headers/link'
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/CoverageDiscoveryTask'
'401':
$ref: '#/components/responses/PermissionDeniedError'
'403':
$ref: '#/components/responses/ForbiddenError'
5XX:
$ref: '#/components/responses/UnexpectedError'
/rcm/eligibility/v1/coverage-discovery/x12:
post:
operationId: postDiscoveryX12
tags:
- Coverage Discovery
summary: Submit new discovery task(s) with EDI
security:
- oAuth:
- create_coveragediscovery
description: '
## Overview
__You must be enrolled in the Coverage Discovery feature in order to use this system.__
Coverage Discovery paths and add-ons are enabled per customer and are not included automatically.
Coverage Discovery is an async process that initializes discovery paths based on the task(s) enabled for the customer and on the details of the provided `x12-270` and `x12-271`. Both fields are required. This direct X12 workflow is often simpler than the canonical JSON discovery workflow because it allows clients to submit the processed X12 pair without mapping into two canonical models. If successful, the initial response is either a 202 Accepted receipt for a single record or a 207 Multi-Status response if more than one record was produced from the request and the customer has more than one enabled task.
Coverage Discovery is asynchronous because some paths involve chained clearinghouse work and additional connected workflow dependencies. Most non-Coverage-Insight paths are near real time relative to traditional discovery workflows. Customers with strict turnaround sensitivity should evaluate Coverage Insight enrollment carefully.
Coverage Discovery paths may also participate in customer-configured deduplication. This can be enabled per path rather than uniformly across every path. RTCOB and Coverage Insight additionally use a separate non-configurable 72-hour request cache. When that cache is hit, the path is added to `discoveryPaths.skipped` instead of creating a new downstream submission.
To test if the request meets conditions to generate tasks, see the Dry Run section.
## Async Delivery Flow
1. Submit the Coverage Discovery request.
2. If `dryRun` is `false`, the API accepts work for asynchronous processing.
3. For single-task execution, a `202 Accepted` response includes a `location` header for the created discovery task resource.
4. For multi-task execution, a `207 Multi-Status` response returns per-task results, and accepted items include an `href` for each created task resource.
5. If you provide `callbackUrl`, your callback endpoint later receives the completed task payload asynchronously.
6. If needed, you can poll `/coverage-discovery/{id}` using the task resource returned in `location` or `href`.
## Dry Run
To validate that your request meets expected conditions for the paths enabled for your customer, include `dryRun = true` in the request body. In dry-run mode, the request does not execute discovery, does not create task records, and does not send a callback. Instead, the endpoint validates the request against the enrolled discovery paths. The response indicates which paths qualified and which did not.
If successful, the first response is a receipt with either a 200 status for a single task or 207 if the request produced more than one per-task outcome. If no paths qualify, a 422 will be returned for a single task, and a 207 for multi-task responses that include one or more 422 results (see `DryRunMultiStatusMixedResponse` example).
### Callback API
Due to the long-running nature of the discovery process, completed task responses can be communicated asynchronously to `request.callbackUrl` when `callbackUrl` is supplied. `callbackUrl` is optional on standalone Coverage Discovery request bodies, including when `dryRun` is `true`. If `callbackUrl` is omitted, use the task resource returned in `location` or `href` to poll for completion.
When supplied, the API specified in the `callbackUrl` that will receive the asynchronous response once discovery finishes must meet the customer-specific whitelisting requirements defined by your team. Please reach out to support if you need to configure whitelisting. This API must meet the callback structure documented in the "CustomerCallbacks" tab.
Your callback implementation should treat deliveries as asynchronous webhook-style notifications and should be prepared to process the same task idempotently if a delivery is retried. The callback payload uses the same `CoverageDiscoveryTask` model returned by `GET /coverage-discovery/{id}`. The most important fields for most clients are the task `id`, task `status`, any error or failure details, and the embedded real-time eligibility content when callback consolidation is enabled.
If you are unsure about the details of your request and how they might produce eligible discovery paths, you can use `dryRun` to test the request without executing any transactions. When `dryRun` is enabled, the response is synchronous and the callback is not invoked.
'
parameters:
- $ref: '#/components/parameters/header-correlation-id'
- $ref: '#/components/parameters/header-subtenant-id'
requestBody:
$ref: '#/components/requestBodies/DiscoveryRequestX12'
callbacks:
response:
'{$request.body#/callbackUrl}':
post:
parameters:
- $ref: '#/components/parameters/header-tenant-id'
- $ref: '#/components/parameters/header-correlation-id'
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CoverageDiscoveryTask'
examples:
Successful Serial Task:
$ref: '#/components/examples/GetCoverageDiscoveryTaskSerialSuccess'
Successful Serial Task With Real Time Response:
$ref: '#/components/examples/GetCoverageDiscoveryTaskSerialSuccessRealTime'
Successful Chained Task:
$ref: '#/components/examples/GetCoverageDiscoveryTaskChainedSuccess'
Failure Serial Task:
$ref: '#/components/examples/GetCoverageDiscoveryTaskSerialFailure'
Failure Serial Task With Real Time Response:
$ref: '#/components/examples/GetCoverageDiscoveryTaskSerialFailureRealTime'
Failure Chained Task:
$ref: '#/components/examples/GetCoverageDiscoveryTaskChainedFailure'
responses:
'204':
description: Return `204 No Content` after successfully accepting and processing the callback payload.
responses:
'200':
$ref: '#/components/responses/DiscoveryDryRunResponse'
'202':
$ref: '#/components/responses/DiscoveryAcceptedResponse'
'207':
$ref: '#/components/responses/DiscoveryMultiStatusResponse'
'400':
$ref: '#/components/responses/BadRequestError'
'401':
$ref: '#/components/responses/PermissionDeniedError'
'403':
$ref: '#/components/responses/ForbiddenError'
'422':
$ref: '#/components/responses/UnprocessableEntityDiscoveryError'
5XX:
$ref: '#/components/responses/UnexpectedError'
/rcm/eligibility/v1/coverage-discovery/{id}:
get:
operationId: getDiscoveryById
tags:
- Coverage Discovery
summary: Find discovery task by ID
security:
- oAuth:
- read_coveragediscovery
description: Returns an individual discovery response with the corresponding ID, if found.
parameters:
- $ref: '#/components/parameters/header-correlation-id'
- $ref: '#/components/parameters/path-discovery-task-id'
responses:
'200':
$ref: '#/components/responses/DiscoveryResponse'
'401':
$ref: '#/components/responses/PermissionDeniedError'
'403':
$ref: '#/components/responses/ForbiddenError'
'404':
$ref: '#/components/responses/NotFoundError'
'422':
$ref: '#/components/responses/UnprocessableEntityError'
5XX:
$ref: '#/components/responses/UnexpectedError'
components:
parameters:
header-tenant-id:
in: header
name: x-optum-tenant-id
schema:
type: string
example: 9fb77454-8c58-4345-aa50-43f133e06d20
required: true
description: The unique ID of the tenant that invoking user belongs to. Used to enforce data tenancy.
query-task-status:
in: query
name: status
required: false
explode: false
schema:
type: string
enum:
- success
- failure
- pending
example: pending
description: (Optional) When provided, only discovery tasks with the specified status will be returned. Valid values are 'success', 'failure', and 'pending'.
query-sort-discovery:
in: query
name: sort
required: false
explode: false
schema:
type: array
items:
enum:
- startDateTime
- -startDateTime
example:
- -startDateTime
description: (Optional) The property to order the results of the report by. Defaults to '-startDateTime', negative sign is 'desc'
header-subtenant-id:
in: header
name: x-optum-subtenant-id
schema:
type: string
example: 5e2f9f4f-6f1d-4b37-92b5-6c5a9d1f8a21
required: false
description: (Optional) Identifies an Optum-assigned sub-tenant configuration for your organization. Include this header only when Optum has provided a value for a specific enabled customer configuration. Clients must not generate or infer this value.
query-start-date-time:
in: query
name: startDateTime
required: false
schema:
type: string
example: '2017-07-21T17:32:28Z'
description: (Optional) The start date for the report. Start date must be before the end date
query-end-date-time:
in: query
name: endDateTime
required: false
schema:
type: string
example: '2017-09-21T17:32:28Z'
description: (Optional) The end date for the report. Must occur after the provided start date
query-offset:
in: query
name: offset
required: false
schema:
type: integer
description: (Optional) Pagination. The offset number to retrieve, which is determined by the limit. For example,if limit is 30 and offset is 0, then the response data will include records 1~30; If offset is 30 and limit is 30 then the response data will include records 30~59.
path-discovery-task-id:
in: path
name: id
description: The unique ID of the target discovery task
required: true
schema:
type: string
example: 36743735-3303-4d9d-9f21-20dd5f6d7ab2
query-correlationid:
in: query
name: correlationId
schema:
type: string
example: 9fb77454-8c58-4345-aa50-43f133e06d20
description: (Optional) The correlationId associated with the original request.
header-correlation-id:
in: header
name: x-optum-correlation-id
schema:
type: string
example: 9fb77454-8c58-4345-aa50-43f133e06d20
required: false
description: (Optional) A unique identifier value that is attached to the response that allow reference to the original request. Differs from `x-optum-trace-id` as the correlation-id is stored within the datastore for future queryability.
query-limit:
in: query
name: limit
schema:
type:
- integer
- 'null'
minimum: 1
maximum: 100
example: 30
description: (Optional) Number of transactions to return per page. Must be greater than 0 and less than or equal to 100. Defaults to 30.
schemas:
EligibilityRequest:
type: object
description: Standalone JSON representation of a standard 270 eligibility request. This schema is fully inlined into this spec so the API definition stands on its own.
required:
- subscriber
- encounter
properties:
submitterTransactionIdentifier:
type: string
description: BHT03
controlNumber:
type: string
minLength: 9
maxLength: 9
description: 'Segment: ISA, Element: ISA13, Notes: Optional. If omitted, Enhanced Eligibility generates the Interchange Control Number. When supplied, it must be exactly 9 positive unsigned numeric characters.'
example: '123456789'
tradingPartnerServiceId:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100A Segment: NM1, Element: NM109, Notes: we send this as MN108 as PI'
example: serviceId
tradingPartnerName:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100A, Segment: NM1, Element: NM103, Notes: organizational name'
provider:
type: object
properties:
organizationName:
type: string
minLength: 0
maxLength: 60
description: 'Loop: 2100B Segment: NM1, Element: NM103'
example: provider_name
firstName:
type: string
minLength: 0
maxLength: 35
description: 'Loop: 2100B Segment: NM1, Element: NM104'
lastName:
type: string
minLength: 0
maxLength: 60
description: 'Loop: 2100B Segment: NM1, Element: NM103'
npi:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100B Segment: NM1, Element: NM109, Notes: NM108=XX Centers for Medicare and Medicaid Services National Provider Identifier. The submitted value must be a valid NPI and follow standard NPI validation rules.'
example: '1234567893'
serviceProviderNumber:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100B Segment: NM1, Element: NM109, Notes: NM108=SV Service Provider Number'
example: '54321'
payorId:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100B Segment: NM1, Element: NM109, Notes: NM108=PI Payor Identification'
taxId:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100B Segment: NM1, Element: NM109, Notes: NM108=FI Federal Taxpayer''s Identification Number'
ssn:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100B Segment: NM1, Element: NM109, Notes: NM108=34 Social Security Number'
pharmacyProcessorNumber:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100B Segment: NM1, Element: NM109, Notes: NM108=PP Pharmacy Processor Number'
servicesPlanID:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100B Segment: NM1, Element: NM109, Notes: NM108=XV Centers for Medicare and Medicaid Services PlanID'
employersId:
type: string
minLength: 0
maxLength: 80
description: 'Loop: 2100B Segment: NM1, Element: NM109, Notes: NM108=24 Employer''s Identification Number'
providerCode:
type: string
description: 'Loop: 2100B Segment: PRV, Element: PRV01'
example: AD
enum:
- AD
- AT
- BI
- CO
- CV
- H
- HH
- LA
- OT
- P1
- P2
- PC
- PE
- R
- RF
- SB
- SK
- SU
referenceIdentification:
type: string
description: 'Loop: 2100B Segment: PRV, Element: PRV03'
example: 54321g
providerType:
type: string
description: 'Loop: 2100B Segment: NM1, Element: NM101'
enum:
- payer
- third-party administrator
- employer
- hospital
- facility
- gateway provider
- plan sponsor
- provider
portalUsername:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: User Identification REF01=JD'
portalPassword:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: Personal Identification Number (PIN) REF01=4A'
informationReceiverName:
type: object
properties:
stateLicenceNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=0B State License Number'
medicareProviderNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=1C Medicare Provider Number'
medicaidProviderNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=1D Medicaid Provider Number'
facilityIdNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=1J Facility ID Number'
contactNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=CT Contact Number'
devicePinNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=EL Electronic Device Pin Number'
submitterIdNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=EO Submitter Identification Number'
nationalProviderIdentifier:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=HPI Centers for Medicare and Medicaid Services National Provider Identifier'
providerPlanNetworkIdNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=N5 Provider Plan Network Identification Number'
facilityNetworkIdNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=N7 Facility Network Identification Number'
priorIdentifierNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=Q4 Prior Identifier Number'
socialSecurityNumber:
type: string
minLength: 0
maxLength: 50
description: 'Loop: 2100B, Segment: REF, Element: REF02, Notes: REF01=SY Social Security Number'
federalTaxpayerIdentificationNumber:
type: string
# --- truncated at 32 KB (152 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/optum/refs/heads/main/openapi/optum-coverage-discovery-api-openapi.yml