US · guidance
CMS Pub. 100-04, ch. 24, § 50.9
Direct Data Entry (DDE) Screens
HIPAA does not require, but does permit payers to maintain DDE screens for claim
submission, correction, claim status determination, and eligibility verification. A/B
MACs (A) are required to maintain claim submission, claim correction and claim status
screens, but not A/B MACs (B) or DME MACs. This section is applicable to claim entry
and claims correction (see chapter 31 for DDE requirements for formats other than
claims).
Medicare considers transactions conducted via DDE screens to meet HIPAA-compliancy
requirements. DDE claims are considered HIPAA-compliant EDI transactions for
application of the 14-day payment floor.
Data entered via DDE screens are not subject to the syntax (format) requirements of the
standards, but must meet “applicable data content” requirements for comparable HIPAA
transactions. A/B MACs (A) may continue to use existing DDE screens for claim
corrections since this function is not subject to HIPAA. DDE systems are proprietary by
definition. They are a direct link between a particular health plan (Medicare) and its
providers, and the software (and sometimes hardware) is unique to and maintained by the
plan. The widespread use of the standard HIPAA transactions should make it
economically feasible for more providers to procure or develop their own EDI products
that can be used with all plans. The use of DDE should decrease over time as a result.
The requirement for “applicable data content” is meant to facilitate that eventual
conversion. Adopting the data content requirements of HIPAA in DDE screens will
facilitate eventual migration of providers from DDE to use of EDI transaction software
(or to use of a clearinghouse). This will also permit maintenance of DDE-generated data
and HIPAA standard transaction-generated data in the same databases.
In this context, “applicable data content” means shared system-maintained DDE screens
must:
• Collect all data elements that are required in the IG as well as those situational
elements that are needed for Medicare processing (unless the data is already
available to the payer’s system);
• Use only the internal and external code sets designated in the HIPAA standard
TR3 with no additions or substitutions;
• Provide for at least the field size minimums noted in the IG, but no more than the
maximum sizes (Do not expand the size of a shared system’s internal claim
records);
• Permit at least the minimum number of field repeats noted in the IG, but no more
than the maximum number;
• Allow for only one investigational device exemption number (IDE) per claim (at
the claim level);
• Remove employment status code, employer name, and employer address
information;
• Allow Other Subscriber Demographic Information (date of birth and gender) if
the other subscriber is a person;
• Allow for discharge hour and minute information in the numeric form of HHMM;
and
• Allow for correct processing of the unique physicians identifier number in the
2310A (Attending Physician) loop.
Data elements not used by-Medicare are not currently collected in Medicare DDE
screens. Claims correction via DDE should be limited to Medicare data (non-Medicare
data in error should be purged with an appropriate error message to the DDE user). With
Medicare data plus some information from shared system files, an IG compliant COB
transaction can be written.
NOTE: See section 60.2.3 for additional DDE edit requirements.
History
(Rev. 2803, Issued: 10-28-13, Effective: 09-17-13, Implementation: 09-17-13)
Provenance
- Source
- cms.gov
- Retrieved
- 2026-08-25
- Edition
- iom-2026-08-25
- Content hash
8f6d57c4ea4b83806e11682a8d969882c50d10f739e458b1af461e87a394ea79
The link goes to the issuing authority’s own document — the one we read to produce this record. Where a source publishes whole titles rather than sections, your browser may need a moment to jump to the provision.
Unofficial copy of government-published law, reproduced from official sources with full provenance. Not an official publication; verify against official sources before relying on it in a filing. Records in the 'guidance' corpus, and only that corpus, are sub-regulatory (interpretive guidelines, survey procedures) and are not binding law. Validity bounds follow each jurisdiction's declared temporalBasis.