Direct Data Entry (DDE) Screens

50.9 - Direct Data Entry (DDE) Screens (Rev. 2803, Issued: 10-28-13, Effective: 09-17-13, Implementation: 09-17-13) 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.