CMS-0057-F adds two reporting obligations on top of the API technical requirements. Annual API usage metrics (unique patients transferred, unique patients with repeat transfers) are due each March 31. Public PA reporting metrics (approval rate, denial rate, average decision time, appeal rate) are due on the payer's public website. Both reports need the underlying API to capture the right resource-level audit data; vendors vary widely in how much of the reporting work is built in versus left to the customer engineering team. Here are six solutions worth a real evaluation in 2026. For broader context, the CMS-0057 implementation series covers the deeper material.
What the Reports Actually Need
The annual API usage report due March 31 asks for unique patients transferred (count of distinct members whose data was accessed via Patient Access in the reporting period), unique patients with repeat transfers (count of members accessed more than once), and similar breakdowns for Provider Access and Payer-to-Payer.
The public PA reporting metrics include approval rate (percentage of submissions resulting in approval), denial rate (percentage resulting in denial), average decision time, and appeal volume and outcome rates. These metrics must be visible on the payer's public website.
Capturing the underlying data is straightforward when the FHIR data tier logs at resource granularity. Producing the report from that data is the work that varies in vendor capability.
1. Smile Digital Health (Reporting Module)
Smile CDR includes a compliance reporting layer that captures the annual API usage data and produces CMS-formatted output. The PA reporting metrics are computed from the Task and Communication resources tracked during the ePA workflow. The platform ships customer-ready report templates rather than requiring custom dashboard construction. This is the most complete reporting-in-platform offering in 2026.
2. 1upHealth Reporting
1upHealth captures the audit data needed for annual API usage reporting and exposes it through reporting endpoints. The PA reporting metrics layer is solid. Some custom dashboard work is still typical for the public PA reporting page; the data feed is reliable but the visualization layer is often the payer's responsibility.
3. InterSystems IRIS for Health (Healthshare Reporting)
InterSystems IRIS for Health leverages the broader IRIS data tier for compliance reporting. The reports use the same data layer that supports analytics and care management. For payers with strong existing IRIS reporting capability, the CMS-0057-F reports extend what is already in place. Greenfield IRIS deployments need more setup time for reporting.
4. Edifecs (Smart Trading Reporting)
Edifecs Smart Trading captures the X12 transaction history alongside the FHIR ePA submissions, which gives a unified view of PA activity across both channels. The annual usage reporting is built; the public PA reporting layer requires additional configuration in most deployments. Plans already running Edifecs benefit from the unified data view.
5. Microsoft Azure Health Data Services (with Power BI)
Microsoft Cloud for Healthcare pairs the FHIR service audit data with Power BI for reporting. The pattern is flexible and powerful for plans already using Power BI as their reporting platform. The trade-off is that the payer builds the specific CMS-0057-F report templates; Microsoft provides the data layer and the visualization tool, not the pre-built reports.
6. Onyx (Network Reporting Integration)
Onyx Technologies provides reporting integration as part of the broader network model. The pattern works for payers running Onyx with shared network infrastructure for Provider Access and Payer-to-Payer. The reporting layer is solid for the network-mediated APIs; payers running the direct Patient Access and Prior Auth APIs separately may need additional integration for the unified annual report.
What "Reporting Built In" Should Actually Mean
A useful test during vendor evaluation is to ask for a sample of the CMS-formatted annual API usage report from a current production customer. Vendors that ship the report as a built-in capability produce it on demand. Vendors that capture the data but leave the report to the customer cannot.
For the IG maintenance question that interacts with reporting (report formats may change as IGs evolve), the Best FHIR platforms with vendor-owned IG maintenance covers the related layer. For the full eight-question RFP framework where reporting is question #5, the Top 8 RFP questions to ask your FHIR vendor before renewing covers each category.