Bindinglaw

US · guidance

CMS Pub. 100-04, ch. 24, § 50.9

Direct Data Entry (DDE) Screens

activein force · 2026-08-25 – presentas-observed

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
View the official source →

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.

Coverage · API docs

Bindinglaw

Point-in-time US law with the receipt attached. Source URL, retrieval time, content hash, and validity dates on every answer.

curl api.binding.law/v1/law/coverage

© 2026 binding.law · a Jubal, Inc. productAttorneys and firms never pay. Ever.
CMS Pub. 100-04, ch. 24, § 50.9 — Direct Data Entry (… · binding.law