slug: optum provider: Optum generated_by: planning/capability-mapping/scripts/classify_capabilities.py model: claude-opus-5 frame: - Healthcare Providers min_confidence: 0.7 capability_model: source: https://github.com/vincentmakes/turbo-ea-capabilities license: CC-BY-4.0 attribution: Turbo EA Capabilities by Vincent Verdet — Turbo EA, https://github.com/vincentmakes/turbo-ea-capabilities, CC BY 4.0 notice: NOTICE edge_count: 68 edges: - tag: Institutional Claims spec_file: optum-institutional-claims-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.95 evidence: '"837 Institutional Claim"; "Claim Submission"; "Claim Validation x12"' reason: Operations validate and submit 837 institutional claims to payers — squarely Claim Production & Submission in the provider revenue cycle. - tag: Professional Claims spec_file: optum-professional-claims-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.95 evidence: '"Claim Submission" (POST /medicalnetwork/professionalclaims/v3/submission), "Claim Validation", "Claim Submission x12"; schemas ClaimInformation, ServiceLine, ClaimPricingRepricingInformation' reason: Operations validate and submit professional (837/835) claims to payers via the clearinghouse — squarely claim production and submission within healthcare revenue cycle. - tag: Check Enhanced Dental Eligibility spec_file: optum-check-enhanced-dental-eligibility-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.93 evidence: checkEnhancedEligibility Check Enhanced Dental Eligibility; schemas EligibilityRequest, BenefitUtilization, InsuranceInfo reason: Pre-service verification of dental insurance coverage and benefits is Eligibility & Benefits Verification. - tag: Benefit Check spec_file: optum-benefit-check-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.92 evidence: 'Pre-service Benefit Check API: Prior Auth, Benefit Coverages, and Referral Inquiry for member services' reason: Operations verify coverage, benefits and prior authorisation before service delivery — squarely Eligibility & Benefits Verification. - tag: Coverage Discovery spec_file: optum-coverage-discovery-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.92 evidence: '''Enhanced Eligibility provides real-time eligibility verification for medical benefit inquiries and optional Coverage Discovery workflows when additional coverage needs to be researched''' reason: Operations submit and retrieve coverage-discovery tasks for insurance eligibility/benefit inquiries (including X12 270/271 style EDI), which is precisely pre-service eligibility and benefits verification. - tag: Eligibility spec_file: optum-eligibility-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.9 evidence: POST /medicalnetwork/eligibility/v3/ "Check Eligibility"; POST /oihub/dental/eligibility/preservice/v1 "Pre-Care Eligibility Check"; schemas Payer, PlanInformation, BenefitsRelatedEntity reason: Operations perform real-time insurance eligibility and benefit checks (including raw X12) prior to service, which is exactly Eligibility & Benefits Verification. - tag: Eligibility Requests spec_file: optum-eligibility-requests-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.9 evidence: 'POST /rcm/eligibility/v1 "Submit a new eligibility request"; POST /rcm/eligibility/v1/real-time/x12 "Submit a new X12 270 eligibility request"; description: "real-time eligibility verification for medical benefit inquiries"' reason: X12 270 eligibility inquiry submission with coverage discovery — plainly insurance coverage and benefits verification before service delivery. - tag: Claim Status API spec_file: optum-claim-status-api-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.88 evidence: '"276 Claim Status"; POST /medicalnetwork/claimstatus/v2/ "Check Claim Status"; schemas Subscriber, Payer, ExtendedClaimStatusResponse' reason: X12 276/277 claim status checking with payers is the status-tracking part of claim production and submission in provider revenue cycle. - tag: Authorization (Orchestration) spec_file: optum-authorization-orchestration-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.85 evidence: POST /authorization/x12 278x215 Prior Authorization Orchestration; schema InquiryJSONRequestWithDetermination reason: X12 278 prior authorization request/response orchestration is pre-service authorization determination, which sits under Eligibility & Benefits Verification (authorisation requirements before service delivery). - tag: Claim spec_file: optum-claim-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.85 evidence: '"This API validates a claim before submission by running a `Claims Pre‑Check` against payer rules, X12 formatting, eligibility, and adjudication logic"; POST /claim/precare/v1 dentalClaimPrecheck' reason: Pre-submission claim validation/scrubbing against payer rules is squarely claim production and submission within provider revenue cycle. - tag: Dental Claim Actions spec_file: optum-dental-claim-actions-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.85 evidence: POST /py/oihub/claim/dnt/submit/v1/graphql dntClaimActions; schemas ClaimSubmissionInput, ClaimSubmissionResponse; 'API for RTS Payer Dental Claim Actions' reason: Submission of dental claims with ClaimSubmission request/response schemas — provider-side claim production and submission through the clearinghouse. - tag: Report spec_file: optum-report-api-openapi.yml capability_id: BC-2870 capability_id_l1: BC-2870 capability_name: Healthcare Revenue Cycle Management confidence: 0.82 evidence: '"Claims Responses And Reports"; "convert_report_277 ...", "convert_report_835 ..."; schemas "ClaimStatusResponse", "ClaimPaymentAdviceResponse"' reason: Retrieval and conversion of X12 277 claim-status and 835 remittance reports for submitted claims — clearly provider revenue cycle, but spans both claim status tracking and cash posting so L1 only. - tag: documentRetrieve spec_file: optum-documentretrieve-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.82 evidence: '"Documentation for Cross Community API to query and retrieve patient data"; POST /api/xc/v1/clinical/document/retrieve "Retrieve patient document"' reason: Cross-community (XCA-style) retrieval of clinical documents from external organisations is operation of health information exchange connections. - tag: documentSearch spec_file: optum-document-search-api-openapi.yml reanchored_from: optum-documentsearch-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.82 evidence: POST /api/xc/v1/clinical/documents/search "Search patient document"; schemas DocumentSearchRequest, PatientDemographics, DocumentMetadataList reason: Cross-community patient/document query against external communities is health information exchange operation, not internal record management. - tag: Attachment Submission spec_file: optum-attachment-submission-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.8 evidence: 'openapi description: ''275 Attachments Transaction''; POST /uploads upload ''Attachment Submission''' reason: X12 275 is the standard claim-supporting-documentation transaction sent to payers; this is claim production and submission in the provider revenue cycle. - tag: CCI Edits APIs spec_file: optum-cci-edits-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.8 evidence: Facility - Fetch CCI Edits for single code; Physician - Fecth CCI edits for multi code conflict view reason: National Correct Coding Initiative edits and modifiers are used to validate code pairs in professional/facility coding and claim scrubbing — medical coding compliance. - tag: Claim Inquiry spec_file: optum-claim-inquiry-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.8 evidence: '"allows users to retrieve claim information and status using GraphQL queries ... claim summary, claim detail, claim Acknowledgement"; schema ClaimAck277SearchResponse' reason: Retrieval of claim status/acknowledgement (277) is the status-tracking element of claim production and submission. - tag: Claim Status spec_file: optum-claim-status-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.8 evidence: POST /oihub/dental/claim/inquiry/v1 claimStatus "Claim Status"; schemas GraphQLClaimStatusRequest, Search277CAInput reason: Dental claim status inquiry (277CA) is claim submission status tracking against payers. - tag: ClaimPreCheck spec_file: optum-claimprecheck-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.8 evidence: POST /pre-service/v1/claim/precheck claimPreCheck; schemas ClaimPreCheckRequest, ClaimPreCheckResponse reason: Pre-submission claim check is claim scrubbing/validation prior to payer submission. - tag: Code Information spec_file: optum-code-information-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.8 evidence: getCodehistory Return Code History for the given cpt/hcpcs/icd9v1/icd10cm/icd10pcs {code}; getAnesBaseUnit Return base units for the given CPT Anesthesia {code} reason: Broad medical coding reference surface (CPT/HCPCS/ICD properties, CCI edits, instructional notes, coder dictionary search) delivering 'on-demand medical coding data and Optum coding tool logic' — squarely medical coding production support. - tag: Code Information APIs spec_file: optum-code-information-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.8 evidence: GET /api/coding/code/{code}/validate validateCode Validate if the given code is valid or deleted or invalid reason: Code validation, code-type resolution, ranges, lay descriptions and ICD-10-PCS root operation definitions are core medical coding production and compliance-checking functions. - tag: Eligibility Transactions spec_file: optum-eligibility-transactions-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.8 evidence: 'GET /rcm/eligibility/v1/transactions "Find all eligibility transactions"; description: "real-time eligibility verification for medical benefit inquiries"' reason: Retrieval and status tracking of eligibility verification transactions within the same Enhanced Eligibility product; supports benefits verification, though the operations themselves are read/lookup of prior inquiries. - tag: Facility Compliance APIs spec_file: optum-facility-compliance-apis-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.8 evidence: POST /app/optum/facility/claim/submit/{compliance-type}/{scenario-number} submitClaim Submit claim; createClaimLine; createClaimDiagnosis; deleteClaimLineEdits; schema FacilityClaimLineEdits reason: Operations build a facility claim with lines and diagnoses, apply compliance edits and submit it — this is institutional claim production, scrubbing and submission within provider revenue cycle. Some ambiguity with coding/charge capture, but the submit + claim-line-edit surface points squarely at claim production and submission. - tag: Modifiers spec_file: optum-modifiers-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.8 evidence: '"on-demand medical coding data and Optum coding tool logic"; "Return all the Modifiers for the supplied {codeype}"' reason: Explicitly medical coding content (modifiers, -51 exempt lists) delivered to coding applications; maps to medical coding management. - tag: Modifiers APIs spec_file: optum-modifiers-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.8 evidence: '"Returns the list of codes associated with a modifier"; "GET /api/coding/code/modifier/{modifier}/validate"' reason: Modifier listing, crosswalk and validation operations on CPT/HCPCS codes — coding production and compliance support. - tag: Revenue Code spec_file: optum-revenue-code-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.8 evidence: getRevenueCodes Return CPT/HCPCS to Revenue code crosswalk for the given cpt/hcpcs {code}; "on-demand medical coding data" reason: Serves medical coding reference content — revenue code properties and CPT/HCPCS-to-revenue-code crosswalks used by coders and billers, mapping to Medical Coding Management. Some overlap with chargemaster stewardship keeps this below 0.9. recovered_from: healthcare-vertical-edges.json - tag: Revenue Codes API spec_file: optum-revenue-codes-api-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.8 evidence: getProcCodesForRevenueCode Fetches procedure codes for corresponding revenue code; getCptHcpcsRequiredRevenueCodes Fetches revenue codes requiring CPT HCPCS reason: Facility revenue-code and procedure-code crosswalk lookups supporting institutional coding and billing edits, i.e. medical coding management within provider revenue cycle. recovered_from: healthcare-vertical-edges.json - tag: Claim Actions spec_file: optum-claim-actions-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.78 evidence: 'schemas: ClaimSubmissionInput, ClaimSubmissionResponse, ClaimTicketInput, LineDetailInput; POST /oihub/claim/actions/v1 claimActions' reason: Operations act on claim submissions and claim tickets/line details, i.e. production and submission/correction of claims to payers. - tag: Modifier CrossWalk API spec_file: optum-modifier-crosswalk-api-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.78 evidence: '"Returns the list of modifierCrosswalk based on the selected cpt or hcpcs code"' reason: CPT/HCPCS modifier crosswalk lookups are medical coding reference content used in coding production and compliance, not clinical documentation or plumbing. - tag: V3 Ingestion spec_file: optum-v3-ingestion-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.78 evidence: '"REST API for ingesting XDR Request in Provide and Register format (P&R) with HL7 V3 payloads"' reason: IHE XDR Provide-and-Register document ingestion with HL7 V3 payloads is health information exchange plumbing for clinical document sharing — Healthcare Interoperability Operations. - tag: Auth Referral Submission spec_file: optum-auth-referral-submission-api-openapi.yml capability_id: BC-2820.10 capability_id_l1: BC-2820 capability_name: Referral Management confidence: 0.75 evidence: '''allows users to search for providers, submit referrals, search referrals, and search prior authorizations''; schemas ReferralSubmitResponse, ProviderSearchResponse' reason: Operations submit and track patient referrals with specialist provider search, which is referral management; prior-authorisation search is a secondary function of the same surface. - tag: CDI Information spec_file: optum-cdi-information-api-openapi.yml capability_id: BC-2830.50 capability_id_l1: BC-2830 capability_name: Clinical Documentation Improvement confidence: 0.75 evidence: getCDICodeLinks Return the list of CDI documents for the given code reason: Clinical Documentation Improvement reference content linked to diagnosis codes supports CDI query and education programmes. - tag: Code History APIs spec_file: optum-code-history-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.75 evidence: GET /api/coding/code/{codetype}/{code}/history codeHistory Fetches the complete history for a code reason: Code Search Service exposing history of medical code sets (CPT/HCPCS/ICD) — reference content consumed by medical coding production and audit, i.e. Medical Coding Management. Thin single-operation surface, hence moderate confidence. - tag: Code Specific Guidelines spec_file: optum-code-specific-guidelines-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.75 evidence: GET /codetype/icd10pcs/{code}/code-specific-guidelines Show Code Specific Guidelines for the given ICD10PCS code reason: Delivers ICD-10-CM/PCS code-specific coding guidelines — reference logic used by coders to assign codes correctly, i.e. medical coding management support. - tag: Code Specific Guidelines APIs spec_file: optum-code-specific-guidelines-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.75 evidence: fetchCodeSpecificArticlesList Fetch current year code specific guidelines articles list reason: Serves current-year code-specific coding guideline articles for facility and physician coding, supporting medical coding production and compliance. - tag: Coding Tips API spec_file: optum-coding-tips-api-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.75 evidence: getCodingTips Fetches the list of codingTips for CPT or HCPCS codes reason: Delivers CPT/HCPCS coding tips and annotations for physician coding — direct support of professional-fee medical coding production. - tag: Cross Coder API spec_file: optum-cross-coder-api-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.75 evidence: POST /api/optum/common/cross-coder/list/hcpcs/{code}/i10_cm getCrossCoderDataListI10CM 'Fetches cross coder table data' reason: Cross-walks HCPCS and CPT procedure codes to ICD-10-CM diagnosis codes — medical coding production support for provider billing. Could alternatively sit under BC-2900.20 coding operations; chose revenue-cycle coding as the primary use of cross-coder content. - tag: DRG Codes spec_file: optum-drg-codes-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.75 evidence: Optum Real-Time eContent web services provides access to both ondemand medical coding data ... GET /codetype/drg/{code}/properties reason: On-demand medical coding content lookup for DRG codes — supports medical coding production. recovered_from: healthcare-vertical-edges.json - tag: DRG Information APIs spec_file: optum-drg-information-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.75 evidence: GET /api/cms/facility/{codetype}/{code}/drgs drgCodesForIcdCode 'Fetches the DRG codes for given icd code'; getI10CodesForDrgCode reason: ICD-to-DRG and MDC mapping content used to assign inpatient diagnosis-related groups — medical coding reference and grouping logic for facility billing. - tag: Notes Information APIs spec_file: optum-notes-information-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.75 evidence: '"Fetches CPT or I10CM notes"; "Fetches I10CM chapter notes"' reason: CPT/ICD-10-CM chapter, section and code notes are official coding guideline content consumed by coders; maps to medical coding management, not clinical note documentation. - tag: ProviderAccessBulkMemberMatch spec_file: optum-provideraccessbulkmembermatch-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.75 evidence: '"FHIR Provider Access APIs"; POST /oihub/fhirprovideraccess/v1/R4/{payerId}/{lob}/Group/$bulk-member-match with schemas Patient, Coverage, Consent, GroupMember' reason: Da Vinci/CMS Provider Access FHIR operation that matches a provider's patient panel to payer members so clinical/claims data can be shared — health information exchange / FHIR endpoint operations. Some ambiguity as it is payer-side plumbing rather than a provider process. - tag: ProviderAccessDaVinciExport spec_file: optum-provideraccessdavinciexport-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.75 evidence: '"FHIR Provider Access APIs"; POST /oihub/fhirprovideraccess/v1/R4/{payerId}/{lob}/Group/{groupId}/$davinci-data-export' reason: Da Vinci bulk data export of patient/member records over FHIR R4 — operation of FHIR endpoints and provider-payer data sharing, i.e. healthcare interoperability operations. - tag: APC Cross Codes APIs spec_file: optum-apc-cross-codes-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.72 evidence: GET /api/cms/facility/{apctype}/{code} 'Facility - Fetches CPT/HCPCS Code Specific APC Cross Codes' reason: CMS Ambulatory Payment Classification cross-walks between CPT/HCPCS codes and APC groups — reference content used for facility outpatient coding and reimbursement grouping, i.e. medical coding within revenue cycle. recovered_from: healthcare-vertical-edges.json - tag: DRG Calculator APIs spec_file: optum-drg-calculator-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.72 evidence: POST /api/optum/facility/drg-calculator/ calculateDrg 'Fetches the data of DRG calculator'; schema DrgCalculatorRequest reason: DRG grouping/calculation for facility encounters is an inpatient coding and reimbursement-grouping function within revenue cycle coding. Single operation, hence moderate confidence. - tag: NextQuestion spec_file: optum-nextquestion-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.72 evidence: '"FHIR Prior Authorization APIs (CDS, DTR, PAS)"; POST ".../fhirpriorauth/v1/fhirpa/R4/{payerId}/{lob}/Questionnaire/$next-question"' reason: Adaptive DTR questionnaire step in a payer prior-authorisation flow; prior-authorisation requirement determination sits under eligibility, benefits and authorisation verification before service delivery. - tag: APC Calculator APIs spec_file: optum-apc-calculator-apis-api-openapi.yml capability_id: BC-2870 capability_id_l1: BC-2870 capability_name: Healthcare Revenue Cycle Management confidence: 0.7 evidence: POST /api/optum/facility/outpatient-claims/ outpatientClaims 'Fetches the data of APC calculator'; schemas ApcCalculatorRequest, ClaimLine reason: Ambulatory Payment Classification calculation on outpatient claim lines is provider reimbursement/claim pricing work, sitting in healthcare revenue cycle; the evidence does not pin a single sub-capability (coding vs expected-reimbursement modelling), so only the L1 is asserted. - tag: Attachment spec_file: optum-attachment-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.7 evidence: '''Create attachment container'', ''Commits the attachment container and files'', ''Get participating payers'', ''Get payer business rule''' reason: Dental claim attachment containers submitted against payer business rules are part of producing and submitting supporting documentation with claims to payers, i.e. claim production and submission. - tag: CC/MCC Code and Excludes List for I10CM and I9V1 APIs spec_file: optum-cc-mcc-code-and-excludes-list-for-i10cm-and-i9v1-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: getCCMCCCodeList Fetches the CC MCC codes table data for I10CM and I9V1 codetype reason: CC/MCC (complication/comorbidity) code reference for ICD-10-CM supports DRG assignment and inpatient medical coding. - tag: CCI Edits Code Validator API spec_file: optum-cci-edits-code-validator-api-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: fetchValidCodes Returns list of valid codes from a string of comma separated codes reason: Validation of procedure codes against CCI edit rules supports coding production and compliance checking; thin surface so moderate confidence. - tag: Coding Support spec_file: optum-coding-support-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: getDocuments Show E&M Coding Assitant or Auditors Desk Reference documents reason: Returns E&M coding assistant and auditor reference documents per code — reference material for coding production and coding compliance auditing. - tag: Color Codes spec_file: optum-color-codes-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: GET /codetype/cpt/{code}/color-codes getColorCodes Show Color Codes for the given CPT code reason: '''Color codes'' here are the coding-manual edit icons/flags attached to CPT/HCPCS/ICD codes (not UI styling), used by coders when assigning codes; part of medical coding reference content.' - tag: Color codes APIs spec_file: optum-color-codes-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: fetchColorCodes Fetches new , revised or deleted color codes; fetchI9V3MedicareCodes Fetches I9v3 Coverage color codes reason: Exposes coding-manual edit flags (age, sex, manifestation, Medicare coverage, new/revised/deleted) for CPT/HCPCS/ICD code sets — medical coding reference logic supporting coding production and compliance. - tag: Create Attachments spec_file: optum-create-attachments-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.7 evidence: POST /attachments/documents createAttachments 'Create Attachments by Uploading Documents'; 'Services requests for Dental Attachments for both Provider and Payer users' reason: Although the mechanic is a document upload, the domain is dental claim attachments exchanged between provider and payer — supporting documentation attached to claims, i.e. claim production and submission. Confidence moderated because the single operation is generic upload. - tag: Determination spec_file: optum-determination-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.7 evidence: POST /determination/x12 — "278x215 Prior Authorization Determination"; schema InquiryJSONRequestWithDetermination, AuthorizationJSONResponse reason: X12 278 prior-authorization determination request/response. Provider-side this is pre-service authorisation, which the candidate list places under Eligibility & Benefits Verification ("authorisation requirements before service delivery"). Some ambiguity with Utilisation Management (BC-2820.50), which is why confidence is moderate. - tag: HCPCS Table of Drugs API spec_file: optum-hcpcs-table-of-drugs-api-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: GET /api/optum/facility/hcpcs-drugs getHCPCSDrugsList Fetches HCPCS drugs table data reason: Serves HCPCS (Healthcare Common Procedure Coding System) Table of Drugs reference content, which is coding reference data used to assign billing codes for drugs — supporting medical coding within the provider revenue cycle. Reference-data-only nature keeps confidence moderate. recovered_from: healthcare-vertical-edges.json - tag: MCE Associated ICD10 APIs spec_file: optum-mce-associated-icd10-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: getMCEAssociatedICD10ParentCode Fetches the mce associated codes table data for mce icd 10 parent code reason: Medicare Code Editor associated ICD-10 code tables are coding-compliance reference content used by inpatient/outpatient coders, i.e. Medical Coding Management. - tag: MCE Edits ICD9 and ICD10 API spec_file: optum-mce-edits-icd9-and-icd10-api-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: getMCEEditsICD10 Fetches MCE Edits data based on icd10code reason: Medicare Code Editor edits applied to diagnosis/procedure codes are coding compliance content within revenue cycle medical coding. - tag: Mapping APIs spec_file: optum-mapping-apis-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: i10cmToi9v1Mapping Fetches I10CM to I9V1 mappings on requested Codetype and code reason: ICD-9/ICD-10 code crosswalk lookups are medical coding support content for provider coding operations. - tag: Medicare Fee Schedule APIs spec_file: optum-medicare-fee-schedule-apis-api-openapi.yml capability_id: BC-2870 capability_id_l1: BC-2870 capability_name: Healthcare Revenue Cycle Management confidence: 0.7 evidence: fetchMedicareFees Fetches MPFS fee schedule; getGlobalDays Fetches MPFS global days for CPT and HCPCS code reason: Medicare fee schedule amounts, payment indicators and global-day rules are reimbursement reference data for provider revenue cycle pricing and expected-payment calculation. - tag: Payersheet spec_file: optum-payersheet-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.7 evidence: 'POST .../payer-sheet-service/telecomFormat/fetch getClaimFormat Fetch Claim Format; schemas: JsonClaimFormat, JsonTransmission, JsonSegmentField' reason: Manages payer-sheet claim formatting rules (NCPDP telecom segments/fields) used to construct and transmit claims to payers, which is claim production and submission. - tag: ProviderAccessDaVinciExportDownload spec_file: optum-provideraccessdavinciexportdownload-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.7 evidence: GET .../download/Group/{fileName}/$davinci-data-export — downloadDaVinciExportFile; schemas Patient, HumanName, IdentifierWithType reason: Retrieval of the exported FHIR patient data file from the Da Vinci Provider Access exchange; same interoperability capability, though the operation is a file download step. - tag: QuestionnairePackage spec_file: optum-questionnairepackage-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.7 evidence: '"FHIR Prior Authorization APIs (CDS, DTR, PAS)"; POST .../fhirpriorauth/v1/fhirpa/R4/{payerId}/{lob}/Questionnaire/$questionnaire-package; schemas Claim, Coverage, QuestionnairePackageRequest' reason: Da Vinci DTR questionnaire-package retrieval used to satisfy payer prior-authorisation documentation requirements before service — authorisation/coverage requirement verification. Some chance it belongs with claims/coding instead, hence 0.7. - tag: Reference Code spec_file: optum-reference-code-api-openapi.yml capability_id: BC-2870.20 capability_id_l1: BC-2870 capability_name: Medical Coding Management confidence: 0.7 evidence: '"provides access to both ondemand medical coding data and Optum coding tool logic"; getAnnotations "Return Annotations for the given hcpcs/icd9v1 {code}"' reason: Delivers ICD/HCPCS code sets, ranges, annotations and includes/excludes notes used by coders, supporting medical coding production and compliance; it is reference content rather than coding workflow, so not fully certain of the sub-capability. recovered_from: healthcare-vertical-edges.json - tag: Reports spec_file: optum-reports-api-openapi.yml capability_id: BC-2870 capability_id_l1: BC-2870 capability_name: Healthcare Revenue Cycle Management confidence: 0.7 evidence: '"Claims Responses And Reports"; "list_reports_v2_reports_get List Reports"' reason: Listing of claim response/report files from the medical network clearinghouse; supports claim submission and remittance workflows, though the single list operation is thin for a sub-capability. - tag: Submission spec_file: optum-submission-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.7 evidence: '"278x217 Prior Authorization Submission"; schema "AuthorizationSubmissionJSON"' reason: X12 278 prior-authorisation submission is pre-service authorisation of coverage, which the frame places under eligibility/benefits and authorisation verification; could alternatively be read as utilisation management, hence 0.7. - tag: Telecom Format spec_file: optum-telecom-format-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.7 evidence: '"NCPDP Format Request Data" with schemas ClaimV1, PharmacyV1, InsuranceV1, NCPDPRequestConverterV1Response' reason: Formats pharmacy claim request/response data into the NCPDP Telecommunication standard — i.e. production and formatting of claims for submission to payers, part of healthcare revenue cycle claim production. Some ambiguity as it is a pure format converter. recovered_from: healthcare-vertical-edges.json - tag: UB04 Code Lists spec_file: optum-ub04-code-lists-api-openapi.yml capability_id: BC-2870 capability_id_l1: BC-2870 capability_name: Healthcare Revenue Cycle Management confidence: 0.7 evidence: '"Fetches the list of UB04 codes on codetype" (getUb04Codes)' reason: UB-04 is the institutional claim form; the API serves its code lists (condition/occurrence/revenue codes) used to code and produce facility claims. Revenue-cycle L1 asserted; the specific sub-capability (coding vs claim production) is not determinable. - tag: submitter-api-request-http-controller spec_file: optum-submitter-api-request-http-controller-api-openapi.yml capability_id: BC-2870.30 capability_id_l1: BC-2870 capability_name: Claim Production & Submission confidence: 0.7 evidence: POST /pharmacy-claims sendMessage; schemas SubmitterRequest, SubmitterResponse; "Submitter API Service" reason: The single operation submits pharmacy claims through Optum's clearinghouse submitter service, which is claim production and submission to payers. Confidence held moderate because the operation is a generic 'sendMessage' with no explicit scrubbing/status semantics, though the /pharmacy-claims path and Submitter naming ground the claim-submission reading.