The problem UCRN solves
When a hospital submits claims electronically (via 837 EDI), the claim is identified by a claim number (submitter ID). But the hospital’s internal billing system tracks patients by account number. These are often different identifiers. Later, when a payer sends back a remittance (835 EDI), it references the claim number. To reconcile the payment back to the patient’s account, you need a mapping between the two.
Without UCRN, there’s no way to connect the dots.
File format
UCRN files are pipe-delimited CSVs uploaded to theUCRN/ SFTP folder.
Required fields:
Example file:
How UCRN is processed
1
File ingestion
Our file processor reads the pipe-delimited file and creates an entity for each row with the UCRN data and customer identifier.
2
Background service picks it up
Our account creation service subscribes to entities with UCRN data and processes them in batches.
3
Account lookup or creation
For each UCRN entry, the service:
- Searches for an existing Account entity by account number
- If none exists, creates a new Account entity with the customer’s slug
- Searches for existing Claim entities by the claim submitter ID
4
Linking
The service links Claims to Accounts via entity edges (parent-child relationships). This creates the association that allows the platform to group all claims under a patient account.
Result
After UCRN processing, Claims are linked as children of the Account:- Account 67890
- Claim 12345 — linked by UCRN
- Claim 12346 — linked by UCRN
- Claim 12347 — linked by UCRN
Customer-specific behavior
Different customers may have different account creation logic:- Standard UCRN: Account number comes directly from the UCRN file
- Custom logic: Some customers derive account numbers from claim data (e.g., first 7 characters of the claim submitter ID)