After deliberating with impacted parties over a twelve month period, the Accredited Standards Committee (ASC) X12 approved the ANSI X12N 5010 837 Post Adjudicated Claims Data Reporting (PACDR) guides in August of 2012. These guides define the transaction sets used to exchange post adjudicated claims data for institutional, professional, and dental claims. Although expected in coming months, an ANSI X12N reporting guide for an APCD eligibility file has not yet been approved by the ASC. The approval of the PACDR guides has finally resulted in national industry adopted standards that define the sources of data used to populate the APCD medical and dental claims files submitted to state regulatory agency trading partners administering APCD’s who are defined as public health authorities under HIPAA.

While there is no question that the adoption of the PACDR guides will provide more clarity to data submitters and APCD administrators, resulting in more accurate and timely data, significant confusion still exists regarding the method of transmission of the data files from the payers to the state agencies. The second paragraph of the Preface to the PACDR guides states that: “Trading partners define their specific transport requirements separately. Neither ASC X12 standards or Type 3 Technical Reports define transport requirements.” Given this ambiguity, considerable discussion has taken place between data submitters and administrators over the past six months regarding the most efficient and cost-effective mode of data transmission. Historically, APCD files (with one exception) have been formatted and submitted as standard ASCII, comma delimited, text files. The PACDR guides infer that the medical and dental claims files be submitted in an Electronic Data Interchange (EDI) format, using the applicable X12N Transaction Set structure (segments, data elements, levels, loops) found in the PACDR guides.

While clear benefits exist to using an EDI format in the claims transaction world due to the large number of variations that can exist within the health care claims system, an EDI format provides the flexibility and space savings that are not achievable using a flat file configuration. This is important when receiving vast numbers of claims daily from different payers offering a large variety of policy configurations, coupled with various remittance arrangements resulting from diffuse contracted payment provisions. However, although APCD data files can be quite large (millions of records), the files are not transmitted daily, but monthly, quarterly, and, in some cases annually. The files are also more prescriptive in nature, with few if any situational data elements included in the files. Furthermore, these data do not include all claims transactions and are usually modified or aggregated within the payers’ data warehouses prior to submission. Consequently, moving to an EDI format may not create large efficiencies and cost savings in the data collection and processing phases of an APCD.

If a state APCD administrator is considering utilizing an EDI format for medical and dental claims, consideration should also be given to the following:

• As mentioned previously, an X12N reporting guide does not yet exist for an APCD eligibility file and will continue to be submitted in a standard ASCII text file format until such time that one is created and will then need to be converted.
• Provider files and other ancillary files will be submitted in a standard ASCII text file format and there is no plan at this time to produce a separate X12N provider (or any other ancillary) file reporting guide.
• Medicaid, Medicare A and B Chronic Condition Warehouse files, and possibly the Medicare D files will all need to be transformed and mapped to the commercial claims structure and will also have an ASCII text file structure and not an EDI structure.
• The National Council for Prescription Drug Programs (NCPDP) Post Adjudication Standard Implementation Guide (adopted in October of 2011 by the NCPDP Advisory Board) is in a format which is different from the PACDR guides and also will be submitted in an ASCII text format.

From a data processing perspective, receiving and auditing claims data in two different formats may lead to inefficiencies and increased costs for both data submitters and APCD administrators due to the additional coding and monitoring of two separate pre-processing systems.

Lastly, many state-government administered APCD’s include data elements in the medical files that are not found in the PACDR guides, but have been adopted by the APCD Council. If an EDI format is used, it is unclear how these elements will be submitted if they have not been included within the PACDR X12N Transaction Set structure (segments, data elements, levels, loops).

Although most third-party APCD vendors (including Milliman) have the capabilities to receive claims data in both EDI and ASCII formats, APCD administrators, with input from data submitters, should carefully consider which transmission method is the most cost effective and least disruptive. Making the wrong choice may result in creating more complications and costs to an already complicated and expensive undertaking.