Real Dental API Release Notes

Active release

API Name	API Version	Release Date	Active
Real Pre-Care Estimate	v1	03/31/26	✅
Real Pre-Care Eligibility	v1	05/06/26	✅
Real Claim Submission	v1	05/06/26	✅
Real Dental Attachments	v1	05/06/26	✅

API Name	API Version	Active
Real Claim Status	v1	⏳
Real Electronic Remittance Advice	v1	⏳
Real Dental Attachment API with Image Intelligence	v1	⏳

Legend

Fixes collectively delivered:

Key improvement	Implementation	Changes
Accurate CAS Derivation and Financial Balancing (835D)		A major enhancement was made to ensure accurate financial representation in the generated 835D responses, aligning with UHC Claim Submission API outputs.
	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 are 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:	OA applied with zero allowed amount

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

Enhancement	Implementation	Changes
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
Robust Correlation Logic
	Introduced multi-key mapping using:	Primary: LX Secondary: procedure code, charge amount, units
	Ensured backward traceability using:	ISA13, GS06, ST02 identifiers
Quality & 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.

Enhancement	Implementation	Changes
837D Service-Line Data Persistence with Tooth (TOO) Defaults
	Strengthened 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.

Enhancement	Implementation	Changes
Pre-care (UHC Trial Claim) Response Correlation & REF Propagation
	Improved 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.

Resolution/Enhancement	Implementation	Changes
JSON Response “Message” Alignment with 277CA Outcomes
	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 (May 25, 2026)	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	Implementation	Changes
Enriched STC Segments in 277CA Responses
	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
	Enhancement	The 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.

Validation Fix	Implementation	Changes
CDT Procedure Code Validation Fix
	Addressed 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.

Previous Release	Implementation	Change
Earlier the payer-generated 277 response files were returned
	Returns the payer-generated 277 CA response files	277 CA response files