10 min read

Clearinghouse Setup

ArkCloud sends professional claims (837P), and institutional claims (837I) for a facility that bills on the UB-04, to one clearinghouse through that clearinghouse's SFTP mailbox, and collects its 999, 277CA and 835 replies from the same mailbox. The same mailbox carries 276 claim status inquiries and their 277 answers, and batch 270 eligibility inquiries and their 271 answers. It is vendor-neutral and ships switched off: until a platform operator enters the mailbox credentials, a submission is refused as not configured and the claim stays pending, and no inquiry is sent.

How It Works

Which payers you can reach depends entirely on the clearinghouse you enroll with - ArkCloud has no payer network of its own. ArkCloud's side is the file exchange:

Upload

Each submitted claim is built as an 837P, or an 837I for a facility that bills on the UB-04, and uploaded; it is marked Submitted only once the upload succeeds

Collect

Every 15 minutes the worker collects 999, 277CA, 277, 271 and 835 files from the inbound directory

Apply

Acknowledgements and 277s update claim status; 271s complete eligibility checks; 835s are posted as ERAs to the practice that owns the claims

EDI Transactions Exchanged

837P (Professional claim)

Outbound

Built from an assembled claim and uploaded to the clearinghouse's outbound directory. The claim is marked Submitted only after the upload succeeds.

837I (Institutional claim)

Outbound

Built instead of an 837P when the claim's billing facility has an institutional type of bill set (Settings -> Facilities), e.g. 13 for a hospital outpatient department. Revenue codes, type of bill, patient status and point of origin are required; a claim missing any is refused with every reason listed.

834 (Benefit enrollment)

Inbound

Collected from the inbound directory when it names one of the practice's provider NPIs, or uploaded on RCM -> Enrollment (834). Each member becomes a proposed coverage change - add, change or end - that staff approve or reject. Nothing is written to a patient's coverage without that approval.

999 (Implementation acknowledgement)

Inbound

Collected from the inbound directory and recorded against the batch it acknowledges.

277CA (Claim acknowledgement)

Inbound

Collected from the inbound directory; accepted or rejected status is recorded on the claim.

835 (Remittance advice)

Inbound

Collected from the inbound directory and posted as an ERA. An 835 file can also be uploaded by hand on Insurance -> ERA. The 835 is the only file that posts money.

276 (Claim status inquiry)

Outbound

Once a day, one file per practice asks about each claim still awaiting adjudication 14 days after submission that was not asked about in the previous 7 days. The claim records that it was asked.

277 (Claim status response)

Inbound

The payer's answer to a 276, collected from the inbound directory and applied to the claim's status by the same rules as a 277CA. A 277 never marks a claim paid or posts money, even when it reports a payment; only the 835 does.

270 (Eligibility inquiry, batch)

Outbound

Only when no real-time eligibility connection is configured: checks are queued and sent every 15 minutes as one batch 270 per practice.

271 (Eligibility response, batch)

Inbound

Collected from the inbound directory, matched to the check that asked by its trace number, and recorded exactly as a real-time answer would be.

Eligibility (270/271): real time, or batch through the mailbox

Real-time eligibility checks do not use the clearinghouse mailbox. They call Availity's REST API, and only when AVAILITY_CLIENT_ID, AVAILITY_CLIENT_SECRET and AVAILITY_ORGANIZATION_ID are set - either in the server environment or by a platform operator in the Operator back office -> Credentials, group Availity (real-time eligibility), where a saved value overrides the environment. Without them, and with the clearinghouse mailbox configured, a check is not answered on the spot: it is queued, sent within 15 minutes as part of a batch 270 through the mailbox, and recorded when the payer's 271 comes back. Until then the check is labelled as queued for batch, not as an answer; one with no reply after 72 hours is marked failed. With neither configured, a check is refused in production rather than simulated. Running a check needs the edit_account_details or process_payments permission (Agent, Supervisor and Admin).

Credentials

Entered by a platform operator in the Operator back office -> Credentials, group Clearinghouse mailbox (SFTP), or set as environment variables on the server. A claim is sent only when every required value below is present.

CLEARINGHOUSE_SFTP_HOSTRequired. SFTP host name

CLEARINGHOUSE_SFTP_PORTOptional. 22 when blank

CLEARINGHOUSE_SFTP_USERNAMERequired. Mailbox login

CLEARINGHOUSE_SFTP_PASSWORD or CLEARINGHOUSE_SFTP_PRIVATE_KEYRequired. One of the two (plus CLEARINGHOUSE_SFTP_PASSPHRASE if the key has one)

CLEARINGHOUSE_SFTP_HOST_KEYRequired. The server's SHA256 host-key fingerprint; the connection is refused if it does not match

CLEARINGHOUSE_OUTBOUND_DIRRequired. Where claims are uploaded

CLEARINGHOUSE_INBOUND_DIRRequired. Where replies are collected

CLEARINGHOUSE_ARCHIVE_DIROptional. Processed files move here; blank deletes them

CLEARINGHOUSE_RECEIVER_IDRequired. The clearinghouse's ID (ISA08 / GS03 / 1000B), from its enrollment packet

CLEARINGHOUSE_RECEIVER_NAMEOptional. Defaults to the receiver ID

CLEARINGHOUSE_SUBMITTER_IDOptional. Your ID at the clearinghouse; the billing NPI when blank

CLEARINGHOUSE_ISA_QUALIFIEROptional. ZZ when blank

CLEARINGHOUSE_SUBMITTER_CONTACT_PHONE or CLEARINGHOUSE_SUBMITTER_CONTACT_EMAILRequired. One of the two: the submitter contact every 837 must carry (1000A PER). Without it each claim is refused before it is built

CLEARINGHOUSE_SUBMITTER_CONTACT_NAMEOptional. Defaults to the billing provider's name

Setup Process

Enroll with a clearinghouse

Choose any clearinghouse that offers an SFTP mailbox for 837P files

Complete its enrollment and any payer enrollments it requires - this happens with the clearinghouse, outside ArkCloud

Obtain the SFTP host, login, directories, host-key fingerprint and receiver ID

Enter the mailbox credentials

A platform operator opens the Operator back office -> Credentials

Fills in the group Clearinghouse mailbox (SFTP) - or the same keys are set in the server environment

A value saved there overrides the environment, and is stored encrypted

Test the connection

Use Test on the Credentials page - a read-only probe that verifies the host key, checks both directories exist and counts the files waiting

With no fingerprint set yet, it reports the host key the server presents (and stops before sending a password), so you can confirm it with the clearinghouse

The test uploads, moves and deletes nothing

Make sure the worker is running

Replies are collected every 15 minutes by a background job

The same worker sends the daily 276 claim status inquiries and the batch 270 eligibility inquiries

That job runs only while the worker service and Redis are running

Without them, claims still upload but no 999, 277CA, 277, 271 or 835 is collected, and no 276 or batch 270 is sent

Submit claims

Insurance -> Claims, open an assembled claim, submit

Submitting needs the submit_claims permission, held by ADMIN only

Watch the first 999 and 277CA before submitting at volume

Not Built

Dental (837D) claims

Real-time claim status - a 276 is answered by a 277 dropped in the mailbox, usually hours or days later

278 prior authorization transactions

AS2 transport - SFTP only

Automatic resubmission of rejected claims - a person corrects and resubmits

Direct connections to individual payers, or any per-payer enrollment workflow inside ArkCloud

More than one clearinghouse mailbox per deployment

Older client code for the Change Healthcare, Availity and Waystar claim REST APIs remains in the repository, but nothing in the application calls it: it is not a claim submission or claim status route.

Best Practices

Check the first acknowledgements

Confirm the first batch produces an accepted 999 and 277CA before submitting at volume - the clearinghouse is the first place a mis-set receiver or submitter ID shows up.

Work rejections promptly

A rejected 277CA leaves the claim needing a correction and a fresh submission by a person; nothing resubmits on its own.

Reconcile 835s

Review posted ERAs on Insurance -> ERA and compare with the clearinghouse's own reports.

Keep the host key current

If the clearinghouse rotates its SFTP host key, the connection is refused until the new fingerprint is entered - by design.

Transport Security

Files travel over SFTP (SSH). What ArkCloud enforces:

Host-key pinning

The server's SHA256 fingerprint must match before any file moves

Encrypted credentials

Values saved in the back office are stored encrypted; passwords and keys are write-only

No simulated submission

A claim is never marked Submitted unless the upload succeeded

Your agreements

The Business Associate Agreement with the clearinghouse is yours to hold

Claims Submission ERA/EOB Processing Claim Scrubbing Payment Gateway

Clearinghouse Setup

How It Works

EDI Transactions Exchanged

837P (Professional claim)

837I (Institutional claim)

834 (Benefit enrollment)

999 (Implementation acknowledgement)

277CA (Claim acknowledgement)

835 (Remittance advice)

276 (Claim status inquiry)

277 (Claim status response)

270 (Eligibility inquiry, batch)

271 (Eligibility response, batch)

Eligibility (270/271): real time, or batch through the mailbox

Credentials

Setup Process

Enroll with a clearinghouse

Enter the mailbox credentials

Test the connection

Make sure the worker is running

Submit claims

Not Built

Best Practices

Check the first acknowledgements

Work rejections promptly

Reconcile 835s

Keep the host key current

Transport Security

Related Topics

Need Clearinghouse Setup Help?