CCLF Claims File Import

Zus supports ingesting Claim and Claim Line Feed (CCLF) files. These are fixed-width positional flat files that CMS delivers to ACOs. Uploaded CCLF files appear as Claim FHIR resources within Zus against enrolled patients.

If you are enrolled in the Zus Risk Adjustment product, these claims are also used to create and close risk gaps.

It's important to enroll your patients before uploading Payer Risk Gap information for them. See our documentation on Enrolling your Patients for more info.

CCLF Upload Process

CCLF imports are handled through SFTP. Reach out to your Zus support representative to set up a secure SFTP connection to the Zus system and a designated claims upload folder. Once the folder is properly mounted, uploading properly formatted CCLF files in that folder will create corresponding Claim FHIR resources.

CMS delivers CCLFs to ACOs, usually on a monthly cadence, and you can provide those files to Zus. Both full-history and incremental deliveries are supported (including runouts), and it is always safe to re-deliver files you have already uploaded (see Re-uploads, Adjustments, and Cancellations).

Supported File Types

Zus ingests CCLF file types 1–5 and 9, as defined in the CMS CCLF Information Packet.

Note: A delivery is processed only once it is complete. All six file types (CCLF1-CCLF5 & CCLF9) must be present before any claims from that delivery are created. A partial delivery (for example, five of the six files) waits unprocessed until the missing file arrives.

Other CCLF file types (CCLF6, CCLF7, CCLF8, and CCLFA) are not currently ingested.

File Naming and Packaging

CCLF files follow the CMS naming convention, which encodes the file type and date:

P.A1234.ACO.ZC1Y26.D260420.T1200010

The ZC segment identifies the file type ZC1 → CCLF1, ZC5 → CCLF5, ZC9 → CCLF9, and so on).

Upload files exactly as CMS names them. Zus uses the file name both to identify each file's type and to group the six files of a single delivery. The files of one delivery must share the rest of their name outside the ZCxYnn segment (ACO, Date-time section, etc). A renamed file lands in its own incomplete delivery and is never processed.

Each file may be uploaded:

• Uncompressed, with a .txt extension or no extension
• As a compressed archive (.gz, .gzip, or zip) containing exactly one file matching the same CCLF file name.

If you send compressed files, upload each file individually: ZIP archives containing more than one file are rejected, as are ZIP archives written in streaming mode (using data descriptors). If you compress, gzip is the most reliable choice. A file that isn't recognizable as plain text, gzip, or ZIP is not processed.

Patient Matching on Import

Before creating or updating a Claim, we require that a Patient record exists in the current builder with an identifier matching the beneficiary's Medicare Beneficiary Identifier (MBI) from the CCLF file, under the standard FHIR MBI system. If no patient matches, the claim is skipped and produces nothing.

{
  "id": "[uuid]",
  "identifier": [{
     "system": "http://hl7.org/fhir/sid/us-mbi",
     "value": "1FA2KE3ME45"
  },
  ... other identifiers
  ],
  ... additional Patient Data
}

Some builders are configured to match on a custom identifier system instead of the standard MBI namespace. Your Zus support representative will confirm which identifier system applies to your builder.

CMS occasionally reassigns a beneficiary's MBI. The CCLF9 cross-reference file lets Zus reconcile claims that reference a previous MBI; and will keep your enrolled patients' MBI identifiers up to date.

Re-uploads, Adjustments, and Cancellations

It is safe to re-upload files or to deliver overlapping claim history. Each claim is identified by its CMS claim unique identifier: re-processing the same claim is idempotent, and a newer version of a claim replaces the older one.

CCLF adjustment and cancellation records are honored. An adjustment supersedes the prior version of the claim, and a cancellation voids it. For risk adjustment purposes, only final action claims — the latest surviving version of each claim after all adjustments and cancellations are resolved — are considered.

What Zus Creates

Each ingested claim becomes a FHIR Claim resource conforming to the Zus claim profile:

https://zusapi.com/fhir/StructureDefinition/claims/zus-claim

• One Claim FHIR resource per CCLF claim, with one Claim.item entry per claim line.
• Claim.status is active, or cancelled for cancellation records.
• Diagnoses are inlined on Claim.diagnosis. No standalone Condition resources are created.
• Line items carry the HCPCS/CPT procedure codes from CCLF2 and CCLF5. The ICD procedure codes from CCLF3 are not currently written to the Claim.
• Coverage information is contained within the Claim. No standalone Coverage resource is created.
• Line-level admission and discharge dates land on Claim.item.servicedPeriod. No Encounter resources are created)