How to Build an Automated 835-to-MRF Pipeline Across Multiple Hospitals and Revenue-Cycle Platforms
Hospital price transparency becomes significantly harder when remittance data is distributed across multiple hospitals, revenue-cycle platforms, clearinghouses, payers, and billing environments.
The challenge is not simply converting an X12 835 file into JSON. A production-grade pipeline must identify the correct hospital and location, normalize payer and plan information, interpret remittance data correctly, calculate CMS-required allowed-amount statistics, generate the required machine-readable file, validate the output, support attestation, and maintain traceability from published values back to source transactions.
This guide explains the architecture and engineering controls required to build that pipeline at scale.
What Is an 835-to-MRF Pipeline?
An 835-to-MRF pipeline is an automated healthcare data workflow that uses electronic remittance advice data to support the allowed-amount calculations required in a hospital’s machine-readable file.
The X12 835 Health Care Claim Payment/Advice transaction carries claim and payment adjudication information, including adjustments and amounts associated with claims and service lines. CMS identifies X12 5010 (835) as the adopted ERA standard.
Under the 2026 Hospital Price Transparency requirements, when a payer-specific negotiated charge for an item or service is expressed as a percentage or algorithm, the hospital must also report:
- Median allowed amount
- 10th percentile allowed amount
- 90th percentile allowed amount
- Count of allowed amounts
CMS requires hospitals to use EDI 835 ERA data, or an alternative equivalent source containing the same information, to calculate those values. The lookback period must be no less than 12 months and no longer than 15 months before the MRF is posted.
The important distinction is that 835 data does not independently generate the entire hospital MRF. The MRF contains the hospital’s broader standard-charge information. The 835 or equivalent remittance source supplies the historical data needed for the applicable allowed-amount calculations.
That distinction should drive the architecture.
Why This Matters for Multi-Hospital Organizations
A single hospital may receive 835 transactions through multiple payers or clearinghouses. A health system can introduce significantly more variation:
- Multiple hospitals and locations
- Multiple EHR or RCM platforms
- Different clearinghouses
- Different payer identifiers
- Different payer-plan relationships
- Different internal billing-code mappings
- Different contract structures
- Different source-system delivery mechanisms
A pipeline designed around one hospital’s file layout will quickly become difficult to maintain.
The scalable approach is to separate source-specific ingestion from canonical remittance processing and from CMS MRF generation.
The Reference Architecture
A production architecture should separate the data flow into distinct layers:
rather than:
835 → JSON
This distinction prevents the entire application from becoming dependent on the structure of a particular payer or RCM platform.
Build the 835 Data Ingestion and Normalization Layer
Step 1: Build a Multi-Source 835 Ingestion Layer
Treat every revenue-cycle or clearinghouse source as an adapter.
RCM Source A ──> Adapter A ┐
RCM Source B ──> Adapter B ├──> Canonical Intake
Clearinghouse ─> Adapter C ┘
The ingestion layer should preserve the original transaction before business transformation. Useful metadata includes:
- Source system
- Source file identifier
- Receipt timestamp
- Transaction control identifiers
- Sender and receiver information
- Processing status
- File checksum
- Raw-file storage reference
A checksum or equivalent fingerprint can help detect duplicate files before downstream processing.
The raw 835 should remain available for audit and troubleshooting. Parsing should create a processed representation without destroying the source.
Step 2: Parse and Validate the X12 Transaction
The next layer validates the X12 envelope and parses the 835 transaction. A simplified structure is:
CMS explains that ERA data can contain adjudication information at claim and line levels and adjustment information at line, claim, or provider level. Adjustment reasons are represented using standardized codes such as Claim Adjustment Group Codes, CARCs, and RARCs.
Separate processing failures into two categories.
Structural errors
Examples include:
- Invalid X12 envelope
- Malformed segments
- Missing required elements
- Invalid transaction control information
- Unsupported transaction structure
Business-data exceptions
Examples include:
- Unknown payer
- Unmapped hospital
- Missing service relationship
- Unexpected adjustment
- Missing calculation input
A structurally valid 835 does not necessarily mean the transaction is ready for an MRF calculation.
Step 3: Create a Canonical Remittance Model
Do not allow the calculation engine to depend directly on payer-specific segment positions.
Instead, normalize the parsed transaction into an internal healthcare remittance model.
For example:
RemittanceRecord
├── hospital_id
├── location_id
├── payer_id
├── plan_id
├── claim_id
├── service_id
├── billing_code
├── modifiers
├── billed_amount
├── allowed_amount
├── paid_amount
├── adjustment_data
├── service_date
├── payment_date
└── source_transaction_id
This is an implementation model, not a CMS-prescribed schema. The purpose is to establish a stable internal representation so that:
835 Source A
835 Source B
835 Source C
can all feed the same downstream calculation engine.
The design principle is simple: Normalize once; calculate consistently.
Step 4: Resolve Hospital and Location Identity
Multi-hospital implementations need deterministic identity resolution. Do not use filenames or internal facility names as the primary identity mechanism. A controlled identity registry can connect source identifiers to the organization’s canonical hospital records:
Source Provider Identifier
|
v
Provider Identity Registry
|
+── Legal Organization
+── Type 2 NPI
+── Hospital Location
+── RCM Platform
+── MRF Configuration
CMS’s 2026 technical changes added Type 2 organizational NPI reporting to the MRF.
However, location handling requires care. A physical location does not automatically mean that a completely separate MRF is required in every circumstance.
The implementation must determine how the hospital’s standard charges are organized and whether locations share the same standard-charge information.
The identity model should therefore distinguish:
Organization
↓
Hospital
↓
Location
↓
Standard-Charge Dataset
↓
MRF
This prevents the common mistake of assuming that every location should simply become a separate MRF.
Step 5: Normalize Payer and Plan Identity
Payer identifiers can differ across RCM systems and clearinghouses. For example:
Source Payer ID
|
v
Canonical Payer
|
+── Payer Name
+── Plan
+── Contract
+── Effective Dates
+── Source Identifiers
Keep both the source identifier and the canonical identifier. Do not overwrite source values.
Effective-dated mappings are particularly important because payer-plan relationships and contracts can change over time.
This is a recommended production architecture, not a CMS-defined database schema. The purpose is to prevent historical remittance records from being reinterpreted incorrectly when mappings change.
Step 6: Establish the CMS Lookback Window
For the 2026 allowed-amount requirements, the hospital must use a period of no less than 12 months and no more than 15 months before posting the MRF.
The pipeline should calculate the reporting window dynamically.
MRF Posting Date
|
v
Determine CMS-allowed lookback period
|
v
Filter eligible remittances
|
v
Build calculation dataset
Store the actual calculation period as metadata:
mrf_posting_date
lookback_start
lookback_end
calculation_run_id
This is important for reproducibility. If a value is challenged later, the team should be able to identify exactly which historical data was used.
Step 7: Identify the Correct Allowed Amount
This is one of the most important parts of the entire pipeline. Do not simply treat the payer payment amount as the allowed amount.
CMS defines the total allowed amount for this purpose as the total amount the hospital was reimbursed for the applicable item, service, or service package.
CMS states that the total allowed amount is derived from:
gross charge − contractual adjustments
and consists of:
- The portion billed to the applicable payer for the particular plan
- The portion, if any, billed to the patient
The allowed amount therefore requires healthcare-specific financial interpretation rather than a simple extraction of one 835 monetary field.
The pipeline should establish explicit rules for:
- Claim-level versus service-line information
- Contractual adjustments
- Patient responsibility
- Reversals
- Recoupments
- Duplicate transactions
- Service/package relationships
- Incomplete records
This is where a production implementation needs domain-specific revenue-cycle logic.
Step 8: Exclude $0 Remittances and Handle Low Counts
CMS explicitly requires hospitals to exclude $0 remittances when calculating and encoding the allowed amounts.
Therefore:
Raw remittances
|
v
Remove $0 remittances
|
v
Qualifying allowed-amount observations
The count also has a specific CMS encoding rule. If the number of qualifying remittances is:
0 → “0”
1–10 → “1 through 10”
11+ → actual whole number
CMS also requires an explanation in the applicable notes field when the count is zero. These are not cosmetic formatting details. They should be implemented as validation rules in the MRF-generation layer.
Step 9: Calculate the Required Statistics
When the payer-specific negotiated charge is expressed as a percentage or algorithm, the MRF must contain:
Median Allowed Amount
10th Percentile Allowed Amount
90th Percentile Allowed Amount
Count of Allowed Amounts
CMS specifies that the percentile calculations use the historical allowed amounts from the applicable lookback period. If a calculated percentile falls between two observed allowed amounts, the next highest observed value must be used.
A conceptual implementation looks like:
qualifying_amounts = eligible observations
sort(qualifying_amounts)
p10 = CMS_defined_percentile(qualifying_amounts, 10%)
median = CMS_defined_percentile(qualifying_amounts, 50%)
p90 = CMS_defined_percentile(qualifying_amounts, 90%)
count = number of qualifying remittances
The function names above are intentionally conceptual.
Do not blindly call a programming-language percentile function and assume the result is CMS-compliant. Generic statistical libraries may use interpolation methods that do not match CMS’s required selection rule.
This is a good example of why the problem is more than software development: the calculation engine must encode the healthcare regulatory rule, not merely perform mathematically valid statistics.
Step 10: Generate the CMS MRF
The 835 calculation engine should feed a separate CMS MRF generation layer. CMS’s current Hospital Price Transparency technical repository provides required CSV and JSON templates, data dictionaries, and JSON schemas. The current v3.0 specification applies to requirements effective January 1, 2026.
The architecture should therefore be version-aware:
Canonical Hospital Data
+
Allowed-Amount Results
|
v
CMS MRF Generator
|
+—-+—-+
| |
CSV JSON
Do not scatter CMS-specific field rules throughout the entire application. Instead, isolate them in a versioned compliance layer:
Data Processing
|
v
CMS HPT v3.0 Mapping
|
v
MRF Output
This reduces the impact of future CMS specification changes.
The 835 Is Not the Entire MRF
This distinction is worth repeating.
A hospital MRF contains broader standard-charge information, including payer-specific negotiated charges and other required hospital charge data. The 835 provides historical remittance information for the allowed-amount calculation when the negotiated charge is expressed as a percentage or algorithm.
Therefore, a complete production architecture normally looks more like:
Hospital Charge / Contract Data
+
Payer / Plan Information
+
835 ERA Data
|
v
MRF Preparation
|
v
CMS MRF
This is much more accurate than presenting the project as a simple EDI-to-JSON converter.
Step 11: Validate the MRF Automatically
Validation should be a mandatory pipeline stage.
CMS provides an official Hospital Price Transparency validator that supports the current Data Dictionary v3.0 and previous versions. It evaluates whether an MRF conforms to the required form-and-manner requirements. A production workflow should therefore look like:
Generate MRF
|
v
CMS Schema/Form Validation
|
+—- Errors → Exception Queue
|
+—- Alerts → Review
|
v
Business Validation
|
v
Attestation Review
|
v
Publication
CMS explicitly warns that passing the validator does not certify that the MRF complies with every Hospital Price Transparency requirement.
That means technical validation and compliance review should remain separate controls.
Step 12: Add the 2026 Attestation Workflow
The 2026 rules replaced the previous affirmation statement with an attestation statement and added an attester name and Type 2 organizational NPI requirements.
The pipeline should therefore include an approval stage:
MRF Generated
|
v
Technical Validation
|
v
Business/Data QA
|
v
Attestation Preparation
|
v
Authorized Review
|
v
Publication
Automation should prepare the data and identify exceptions, but the organization’s designated responsible official remains part of the compliance workflow.
This distinction is important when designing enterprise automation: automate preparation and controls without silently converting an organizational attestation into an unattended software action.
Step 13: Publish the MRF and Maintain Discovery Information
Publishing the JSON or CSV file is not the end of the workflow.
CMS provides cms-hpt.txt tooling to support automated discovery of hospital MRFs. The file contains information such as the hospital location, source page URL, MRF URL, and technical contact information.
Therefore, the publication layer should include:
Validated MRF
|
v
Publish MRF
|
v
Update/Verify cms-hpt.txt
|
v
Verify Public URL
|
v
Automated Accessibility Check
This is particularly important for an automation platform because the objective is not simply to generate a file but to maintain a reliable, publicly accessible MRF publication workflow.
Step 14: Build End-to-End Data Lineage
A production pipeline should make every published value traceable. The lineage should look approximately like:
Published MRF Value
↓
MRF Version
↓
Calculation Rule Version
↓
Mapping Version
↓
Calculation Dataset
↓
Canonical Remittance Record
↓
Parsed 835
↓
Original Source File
Store information such as:
- Source transaction identifier
- Source file identifier
- Processing timestamp
- Hospital/location mapping version
- Payer/plan mapping version
- Calculation-rule version
- MRF specification version
- Validation result
- Exception history
- Publication timestamp
This is especially valuable when the organization needs to explain why a particular allowed amount appeared in a published MRF.
Common Failure Modes
Treating Every 835 as Identical
Different revenue-cycle environments and trading-partner configurations can introduce source variation. Better approach: isolate source adapters and normalize into a canonical model.
Treating Payer Payment as the Allowed Amount
The payment amount alone does not necessarily represent the CMS-defined total allowed amount. Better approach: calculate using the CMS definition, including applicable contractual adjustments and payer/patient portions.
Including $0 Remittances
CMS explicitly requires $0 remittances to be excluded from the allowed-amount calculation. Better approach: enforce the exclusion before statistical calculation.
Using Generic Percentile Functions
A generic statistical library may produce a result using interpolation that differs from the CMS method. Better approach: implement the CMS-specific percentile selection rule and test it against known datasets.
Hard-Coding Payer Identifiers
The same payer can have different identifiers across source systems. Better approach: use controlled, effective-dated payer and plan mappings.
Assuming One Hospital Location Always Means One MRF
Hospital locations and standard-charge datasets do not always map one-to-one. Better approach: model organization, hospital, location, standard-charge dataset, and MRF separately.
Treating Validator Success as Full Compliance
CMS explicitly states that the validator addresses form-and-manner requirements and does not certify full compliance with every HPT requirement. Better approach: combine automated validation with business QA and compliance controls.
Losing Historical Lineage
Without source lineage, resolving a disputed value can require manually reconstructing the entire calculation. Better approach: preserve source, mapping, calculation, validation, and publication lineage.
What a Production-Grade Implementation Actually Requires
The difficult part of an 835-to-MRF implementation is not writing an X12 parser. The real engineering challenge is connecting heterogeneous healthcare systems while preserving the meaning of financial data and applying the correct CMS rules consistently.
A scalable platform should therefore contain five major layers:
1. Connectivity Layer
Connects RCM platforms, clearinghouses, file-transfer systems, and other approved sources.
2. EDI Processing Layer
Receives, validates, parses, deduplicates, and stores X12 835 transactions.
3. Healthcare Normalization Layer
Resolves hospitals, locations, payers, plans, services, contracts, and remittance information.
4. CMS Compliance Layer
Applies allowed-amount rules, lookback requirements, statistical calculations, MRF formatting, and CMS-specific validation.
5. Operational Control Layer
Manages exceptions, audit trails, QA, attestation workflows, monitoring, publication, and ongoing specification changes. This separation allows an organization to add another hospital or revenue-cycle platform without rebuilding the entire pipeline.
Why a Production Pipeline Is More Than Code
A developer can build an X12 parser. That is only one component of the problem. The production challenge looks more like:
The engineering work is therefore distributed across interoperability, revenue-cycle data, healthcare financial logic, regulatory data modeling, quality controls, and operational automation.
That is what makes this a healthcare integration project rather than a simple transformation script.
How CapMinds Can Help
Building an automated 835-to-MRF workflow across multiple hospitals requires more than connecting an EDI feed. It requires an integration architecture that can accommodate different revenue-cycle platforms, normalize healthcare financial data, apply controlled business rules, validate CMS outputs, and maintain operational visibility.
CapMinds can support healthcare organizations with:
- X12 835 integration and processing
- Revenue-cycle platform integration
- Clearinghouse connectivity
- Healthcare data normalization
- Payer and plan mapping
- Multi-hospital integration architecture
- Revenue-cycle data pipelines
- CMS MRF generation workflows
- MRF validation and quality controls
- Data reconciliation and auditability
- Healthcare interoperability engineering
- Custom automation and monitoring
The objective is not simply to produce a machine-readable file. It is to establish a repeatable, auditable, and maintainable healthcare data pipeline that can process heterogeneous revenue-cycle data, calculate the applicable CMS allowed-amount statistics, validate the resulting MRF, support the required attestation workflow, and keep the publication process operational as systems and regulatory specifications change.
Need to evaluate your current 835, RCM, and hospital price-transparency workflow?
Talk to CapMinds about designing the integration architecture, data-mapping strategy, calculation workflow, validation framework, and production automation around your existing healthcare environment.
