API & Services Connection ™
API Reference
Request Sandbox AccessMarketplaceCommunity

Release Notes — Dental Pre-Care Estimate API

This Dental Pre-Care Estimate (GraphQL) API release notes provides information about new features, enhancements, regulatory updates, and any issues or defects that have been addressed from the initial/previous version of the product.

📘

NOTE

Please use the table of contents on the right side of this page to quickly navigate to a desired section.

API NameAPI VersionInitial Release DateAPI ReferenceSupported Payer IdActive
Dental Pre-Care Estimatev103/31/26Dental Pre-Care Estimate (GraphQL) APIUnitedHealthcare: 52133✅

Incremental release updates — 08-10-2026

This includes enhancements to the EDI 835 financial amount reporting and AMT segment addition at both claim and service-line levels.

EDI 835 enhancements

CLP segment enhancement – accurate patient responsibility reporting

Enhanced the logic for populating CLP05 (Patient Responsibility Amount) to ensure the correct patient/member responsibility amount is reported.

Previous BehaviorEnhanced BehaviorFormula
Patient responsibility values were not always accurately reflected in CLP05When the total patient responsibility is greater than $0.00, CLP05 will be populated with the sum of:

  • Deductible Amount
  • Coinsurance Amount
  • Copay Amount
CLP05 = Deductible + Coinsurance + Copay
This ensures compliance with EDI 835 reporting requirements and accurate representation of member financial responsibility

AMT segment addition – claim and service-line levels

New AMT segments have been added to provide enhanced financial reporting.

Claim-Level AMT SegmentService Line-Level AMT SegmentBenefitBusiness Impact
An AMT segment is now generated after the DTM segment within the claim-level (CLP loop)
Sequence:
  • CLP
  • DTM
  • AMT
An AMT segment is now generated after the CAS segment within the service line (SVC loop)
  • SVC
  • DTM
  • CAS
  • AMT
  • Improved visibility of financial amounts at both claim and service line levels
  • Enhanced support for downstream reconciliation and reporting processes
These enhancements provide:
  • Accurate reporting of total patient responsibility in CLP05
  • Detailed patient responsibility breakdown through individual PR CAS segments
  • Standardized CARC/RARC mapping using payer platform codes from LQ02
  • Improved reporting of contractual obligation and adjustment amounts
  • Additional AMT segment support for claim-level and line-level financial reporting
  • Better compliance with EDI 835 transaction standards and improved transparency for providers and trading partners

Incremental release updates — 08-05-2026

This includes several enhancements to the EDI 835 claim payment response generation process to improve the accuracy of claim adjudication details, patient responsibility reporting, adjustment reason mapping, and financial amount reporting at both claim and service-line levels.

EDI 835 enhancements

CAS segment enhancement – adjustment reporting

The CAS segment logic has been enhanced to provide more accurate claim adjustment reporting.

Key UpdateEnhancement DetailBenefitExample
LQ-Based CARC/RARC mappingIntroduced a new LQ segment
  • LQ02 contains the UHC/Payer platform-specific adjustment code
  • This value is cross-referenced against an internal mapping table
  • The mapped CARC/RARC code is then populated within the associated CAS segment
  • Consistent and standardized adjustment reason reporting
  • Improved interoperability for downstream payer/provider systems
Contractual obligation and other adjustment amountsEnhanced the CAS segment processing to report adjustment amounts accurately for:
  • Contractual Obligation (CO)
  • Other Adjustments (OA)
The adjustment amount will now be populated in:
CAS03 = Adjustment Amount
This provides greater transparency into claim-level and line-level payment adjustments
CAS segment enhancement – CARC and RARC Code reportingEnhanced the CAS segment to support standardized adjustment reason reporting through the introduction of the LQ segment
  • A new LQ segment has been added where LQ02 contains the UHC/Payer platform-specific adjustment code
  • The value in LQ02 is cross-referenced against an internal mapping table to identify the corresponding industry-standard CARC (Claim Adjustment Reason Code) and RARC (Remittance Advice Remark Code)
  • The mapped CARC/RARC code is now populated in the CAS03 element of the CAS segment
  • This enhancement ensures that providers receive consistent and meaningful adjustment reason information that aligns with industry-standard EDI 835 reporting practices
  • Improves transparency of claim adjudication results
  • Provides standardized adjustment and denial information
  • Simplifies provider reconciliation and remittance processing
  • Enhances compliance with EDI 835 reporting requirements
CAS*CO*45 ~ (CARC- 45/RARC- N20)

LQ*HE*UHC123~
Where:
  • LQ02 = UHC123 (payer-specific code)
  • Internal mapping identifies the applicable CARC/RARC
  • The mapped value is reported in CAS03
Note: Enhanced the CAS segments to report separate Patient Responsibility (PR) adjustments for Deductible, Coinsurance, and Copay amounts when applicable.

Patient responsibility (PR) CAS segment enhancement

The system now supports reporting individual patient responsibility components as separate CAS segments.

Enhanced logic

A separate CAS segment is generated for each patient responsibility type when the amount is greater than zero.

Responsibility TypeConditionCAS01CAS02CAS03
DeductibledeductibilityAmount > 0PR1Deductible Amount
CoinsurancecoinsuranceAmount > 0PR2Coinsurance Amount
CopaycopayAmount > 0PR3Copay Amount
BenefitExample
  • Provides detailed visibility into individual patient responsibility components
  • Supports more accurate reconciliation by providers and trading partners
If a claim contains:
  • Deductible = $50.00
  • Coinsurance = $20.00
The following CAS segments will be generated:
  • CASPR150.00~
  • CASPR220.00~
If a copay amount also exists:
  • CASPR150.00~
  • CASPR220.00~
  • CASPR3*15.00~

Incremental release updates — 06-10-2026

Here's a summary of changes included:

  • Improved financial accuracy (CAS balancing and reconciliation)
  • Enhanced traceability (LX + REF/6R integrity)
  • Stronger data completeness (TOO defaults and persistence)
  • Accurate provider communication (JSON + STC alignment)
  • Reduced claim rejections (CDT validation and tooth fixes)
  • Better observability and debugging (logs, correlation IDs, test coverage)

The subsequent sections provide detailed information about the fixes/enhancements made.

Correlate and REF/6R from 837D to 835D service lines (no TOO in 835D) — Release (previous 03/25/2026) 03/27/2026

A major enhancement was made to ensure accurate financial representation in the generated 835D responses, aligning with UHC Claim Submission API outputs.

EnhancementDescription
Accurate CAS derivation and financial balancing (835D)
Implemented line-level CAS derivation using
  • PR → Patient Responsibility (deductible, copay, coinsurance)
  • CO → Contractual Obligations (disallowed amounts)
  • PI → Payer Initiated reductions (withholds/adjustments)
  • OA → Other adjustments (e.g., inactive eligibility)
CAS segments now
  • Generated only when amount > 0.00
  • Supporting multiple reason and amount pairs per group
  • Rounded and validated to 2 decimal precision
Financial Integrity Controls
  • Introduced claim-level aggregation for PR, CO, PI totals
  • Implemented reconciliation logic:
    • Sum of adjustments must match chargeAmount within $0.01 tolerance
    • Any imbalance triggers:
      • Translation failure
      • Return of 277 failure response
Special Case Handling
  • Balance billing scenarios:
    • PR assigned when balance billing is allowed
    • CO write-off enforced when prohibited
Eligibility inactive scenarios
  • A applied with zero allowed amount

Result: Eliminates financial discrepancies, ensures audit readiness, and improves payer-provider trust.

EnhancementDescription
Quality and operational improvements
Achieved
  • 100% unit test coverage across parsers, mappers, and builders
  • Complete E2E validation (837D → Trial Claim → 835D)
Added
  • Correlation IDs for traceability
  • Structured logging for debugging
New configuration
  • Optional claim-level NTE generation when REF/6R is missing

Result: Eliminates line-level mismatches and significantly improves troubleshooting capability.

EnhancementDescription
Pre-care (UHC Trial Claim) response correlation and REF propagationImproved accuracy and completeness of response mapping between trial claims and original submissions.
Correlation Strategy
  • One-to-one mapping:
    • Primary Key: Claim ID + LX
    • Fallback: Procedure code, charge amount, units
  • Unmatched lines:
    • Logged for diagnostics
    • Non-blocking to overall transaction
REF\6R Handling
  • All REF/6R values:
    • Returned under each corresponding service line
    • Preserved in original sequence
    • No transformation or data modification applied
Other Rules
  • TOO (tooth details) excluded from 835D output
    • Missing REF scenarios:
      • Explicitly logged for traceability

Result: Guarantees accurate provider-side tracking of service lines and improves transparency.

EnhancementDescription
Robust correlation logic
Introduced multi-key mapping using
  • Primary: LX
  • Secondary: procedure code, charge amount, units
Ensured backward traceability usingISA13, GS06, ST02 identifiers

Provide detailed 277CA rejection responses — Release 06/10/2026

  • Misleading "Message" field in JSON Envelope for Rejected Claims
  • Enriched STC segments in 277CA responses
Enhancement/FixDescription
Resolved inconsistencies between actual adjudication status and API response messaging.
Enhancements
  • Standardized JSON messages:
    • Rejections: "Claim Rejected: <Derived Reason from STC>"
    • Acceptances: "Claim Accepted" (for A1 and equivalent statuses)
Implemented Fix
  • Removed misleading “success” messages for rejected claims
  • Aligned messaging strictly with:
    • 277CA STC status codes
Additional Fix
  • Corrected Begin/End Tooth population logic:
    • Enforced proper boundary mapping as per UHC validation rules

Result: Clear, accurate communication to the provider, reducing confusion and support tickets.

Enhancement/FixDescription
Enhanced diagnostic depth in rejection responses.
New Data Elements
  • STC01-3: Identifies rejecting entity (payer/clearinghouse)
  • STC10 & STC11: Secondary and tertiary rejection codes
  • STC12: Human-readable explanation
Multi-Error Handling
  • Supported multiple rejection reasons:
    • Combined STC10/11 codes
    • Delivered consolidated explanatory narrative via STC12
No Changes
  • Acceptance flows remain unchanged
EnhancementThe extra character is removed if the CDT code is more than 5 characters

Result: Provides actionable, detailed rejection insights, enabling faster issue resolution by the provider.

Show accurate JSON "Message" field on 277CA rejections — Release 06/10/2026

JSON response “Message” alignment with 277CA outcomes

Enhancement/FixDescription
Resolved inconsistencies between actual adjudication status and API response messaging.
Enhancements
  • Standardized JSON messages:
    • Rejections: "Claim Rejected: <Derived Reason from STC>"
    • Acceptances: "Claim Accepted" (for A1 and equivalent statuses)
Implemented Fix
  • Removed misleading “success” messages for rejected claims
  • Aligned messaging strictly with:
    • 277CA STC status codes
Additional Fix
  • Corrected Begin/End Tooth population logic:
    • Enforced proper boundary mapping as per UHC validation rules

Result: Clear, accurate communication to the provider, reducing confusion and support tickets.

Support valid procedure codes in 837 submissions — Release 06/10/2026

FixDescription
Code exceeding 5 characters in LX segment ("D1110A")
CDT procedure code validation fixAddressed critical validation gap causing improper claim rejections
Validation Rules Enforced
  • Accept only valid 5-character CDT codes:
    • Example: D1110
  • Reject:
    • Codes exceeding 5 characters
      • Example: ❌ D1110A
Error Handling
  • Invalid codes:
    • Trigger 277CA rejection
  • Include:
    • Clear STC error codes
    • Human-readable explanation sent back to the provider
Impact
  • Eliminated false negatives for valid claims
  • Provided actionable feedback for correction at source

Result: Ensures compliance with CDT standards while improving provider experience.

EnhancementDescription
837D service-line data persistence with Tooth (TOO) defaultsStrengthened data persistence and completeness for dental service lines
What is stored
  • Full service-line structure:
    • LX, SV3, DTP
    • All REF/6R values in original order
    • TOO (Tooth Info)
Defaulting Rules Introduced
  • If no tooth information provided:
    • Default:
      • Start Tooth = 1
      • End Tooth = 1
  • If only one tooth provided:
    • Automatically populate End Tooth = Start Tooth
Surface mapping
  • Mandatory when a tooth number exists
  • Ensured complete compliance without failure
Error Handling
  • Defaulting logic is non-blocking
  • No rejection triggered due to missing tooth data

Result: Prevents downstream API failures and ensures compatibility with UHC dental processing rules.

EnhancementDescription
LX sequencing and REF/6R preservation (835D integrity fix)Resolved longstanding issues related to line misalignment and traceability
  • Preserved exact LX sequencing from 837D → 835D
  • Ensured REF/6R (Line Control Number) is:
    • Correctly echoed back to its originating service line
    • Supported even in cases of:
      • Duplicate REF values
      • Missing optional segments

Initial release — 03-31-2026

Legend

  • ✅: Active
  • ⏳: Coming soon!
  • ❌: Deprecated
  • End-of-life (EOL): End of support

Updated about 3 hours ago

Did this page help you?

Updated about 3 hours ago

Did this page help you?