API & Services Connection ™
API Reference
Request Sandbox AccessMarketplaceCommunity

Real Dental API Release Notes

This 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.

Initial release

API NameAPI VersionRelease DateAPI ReferenceActive
Real Dental Pre-Care Estimatev103/31/26Dental Claim Pre-Check (GraphQL) API✅
Real Dental Pre-Care Eligibilityv105/06/26Dental Pre-Care Eligibility Check API✅
Real Dental Attachmentsv105/06/26Dental Attachments API✅
Real Dental Claim Submissionv105/06/26Dental Claim Actions API✅

Coming soon!

API NameAPI VersionActive
Real Dental Claim Inquiry APIv1⏳
Real Dental Pre-Service Eligibility APIv1⏳
Pre-Care Eligibility Intelligence (Enhanced Eligibility) APIv1⏳
Real Dental Electronic Remittance Advice APIv1⏳
Real Dental Attachment API with Image Intelligence APIv1⏳

Legend

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

Pre-Care Estimate API V1.0 — 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

Updated 4 days ago

Did this page help you?

Updated 4 days ago

Did this page help you?