Bindinglaw

US · guidance

CMS Pub. 100-04, ch. 28, § 80

Electronic Transmission - General Requirements

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

The outbound COB transaction is a post-adjudicative transaction. This transaction

includes the incoming claim data as well as the COB data. A/B MACs or DME MACs

are required to receive all possible data on the incoming 837, although they do not have

to process non-Medicare data. However, the shared system must store that data in a store-and-forward repository (SFR). This repository file is designed and maintained by the

shared system. This data must be re-associated with the Medicare claim and payment data

in order to create a compliant outbound COB transaction using the Medicare Claim/COB

flat file as input. The shared system is to use post-adjudicative Medicare data (data used

from history and reference files to adjudicate the claim) instead of data received when

building the outbound COB transaction. This is to show any changes in data element

values as a result of claims adjudication. The shared system must retain the data in the

SFR for a minimum of six months.

The Medicare Claim/COB flat file is the format to be used to re-associate all data

required to map to the COB transaction.

Data on claims that the A/B MAC or DME MAC receives from its keyshop or image

processing systems may not be included on the SFR, depending on the shared system

design. The A/B MAC and DME MAC will create the Medicare claim/COB flat file

using data available from claims history and reference files. Since some data will not be

available on these “paper” claims, the outbound COB transaction will be built as a

“minimum” dataset. It will contain all “required” COB transactions segments and post-adjudicative Medicare data.

The steps from receipt of the incoming claim to creation of the outbound COB are

summarized below:

● A/B MACs and DME MACs’ translators perform syntax edits and map

incoming claim data to the ASC X12 flat file;

● Standard system creates any Medicare edits for the flat file data;

● Medicare data on ASC X12 flat file is mapped to the core system;

NOTE: There are no changes in core system data fields or field sizes.

Non-Medicare data (and Medicare data elements where field sizes are in excess of the

core system) are written to the SFR; and adjudicated data are combined with repository

data to create the outbound COB. Under the COBA process, the BCRC will receive flat

files containing processed Medicare claims. The BCRC will then convert the flat files

into the appropriate HIPAA outbound COB format and transmit the claims to the COBA

trading partner.

History

(Rev. 4069, Issued: 06-08-18, Effective: 07-09-18, Implementation: 07-09-18)

Provenance

Source
cms.gov
Retrieved
2026-08-25
Edition
iom-2026-08-25
Content hash
0967e48584dffca68ca3aecd06c0a7b06b44682e13cf96e20912864a80bfab5d
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.