Starting January 1, 2027, payers covered by the CMS Interoperability and Prior Authorization rule generally must run four FHIR-based APIs in production: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. Some earlier obligations, such as faster prior authorization decisions, have applied since January 1, 2026. It's the only hard deadline among the four trends in this article.

Interoperability, patient-facing apps, remote monitoring, and cloud migration all compete for the same budget. Vendors describe each one as urgent. Government surveys, inspector general reviews, and independent research firms paint a more uneven picture.

In our new article, we'll discuss which of the four deserve funding in 2027, which deserve a limited pilot, and where the evidence doesn't support the hype yet.

Key Takeaways

• FHIR: Build now. A federal deadline on January 1, 2027 gives payers no choice, and providers will consume those APIs.
• Patient apps: Build selectively. Portal use is far higher when a clinician recommends it, so tie features to care workflows.
• Remote patient monitoring: Build with guardrails. HHS OIG found that 43% of Medicare enrollees on monitoring missed at least one of three service components.
• Cloud migration: Move in phases. KLAS found only one of 36 surveyed health systems fully in the cloud.
• Vendor and independent figures: They often measure different things, so check what a number counts before it goes into a business case.

FHIR and Interoperability: Build Now

Interoperability is the one trend with a legal deadline attached. CMS finalized the rule in January 2024, and the main API requirements arrive on January 1, 2027.

What CMS-0057-F requires by January 2027

The rule applies to Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care plans, and qualified health plan issuers on the federally facilitated exchanges.

Those payers must run Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs, with compliance dates generally starting January 1, 2027. Since January 1, 2026, payers also have to answer prior authorization requests within 72 hours for expedited cases and seven calendar days for standard ones.

Two details matter for planning. The Prior Authorization API covers medical items and services, so prescription drugs sit outside it. CMS also allows a FHIR-only approach or a FHIR plus X12 278 combination, which means many payers will put a FHIR layer in front of the systems they already run.

Providers face no FHIR build requirement under this rule. They'll consume the payer APIs, and the HL7 Da Vinci implementation guides, including Prior Authorization Support, are the reference CMS points to.

What vendors claim and what hospitals report

A common vendor line is that FHIR is solved. The hospital data is more specific: in 2024, 81% of US hospitals enabled patient access through apps configured to meet API specifications, and 70% did so through apps configured to meet FHIR specifications. The brief draws on the American Hospital Association IT Supplement.

Those figures measure capability. An earlier ASTP/ONC hospital brief noted that some hospitals have the API enabled while few or no app developers have connected to their EHR. An enabled API shows a hospital can exchange data, and it says little about how much data moves.

Small, rural, and independent hospitals trail the national averages, so check readiness organization by organization.

What is worth building?

• A FHIR facade over existing utilization management and X12 systems, so core platforms stay in place.
• SMART on FHIR authorization for apps, using OAuth 2.0 and OpenID Connect.
• Bulk data export to support Provider Access and Payer-to-Payer exchange.
• A conformance test suite that runs against every release.
• Provider-side connectors that call payer Prior Authorization APIs and show status inside the EHR workflow.

On Azure, a managed service such as the FHIR service in Azure Health Data Services covers much of the server layer. We'd spend engineering time on data mapping, authorization, and the connectors around it.

What to skip

We'd skip a custom FHIR server when a managed one fits, and a native FHIR rebuild of core systems when a facade meets the rule. Both feel like long-term investments. Neither is required by CMS-0057-F.

Patient-Facing Apps: Build Selectively

Patient-facing apps have the best usage data of the four trends. The data points to one pattern: people use these tools when their clinician recommends them.

What the usage data shows

Online access to medical records has grown steadily since 2014, and app-based access has climbed since the Cures Act rule took effect, according to ASTP/ONC's analysis of 2024 survey data.

Two findings shape what to build. First, provider encouragement matters most: 87% of people whose clinician encouraged portal use accessed it, compared with 57% of those who weren't encouraged. Second, only 7% of individuals used an app that combines records from several portals, even though most people hold records in more than one.

The source is the Health Information National Trends Survey (HINTS), a self-reported national survey, so treat the percentages as estimates.

What is worth building?

• Features inside the clinical workflow: scheduling, intake forms, test results, clinician notes, and messaging.
• Caregiver and proxy access, which ASTP/ONC reports more than doubled between 2020 and 2024.
• Prior authorization status and referral tracking, using the payer APIs that arrive in 2027.
• Prompts in the visit workflow that point patients to the app, since encouragement drives use.

In our view, the pattern is simple: apps get used when a clinician points patients to them.

What counts as hype

Standalone branded apps with no link to a care team top the list. Record-aggregator apps as a consumer bet come next, given the 7% figure. ASTP/ONC also reports that people mostly use portal apps from EHR developers, healthcare organizations, and insurers.

Market-size figures in vendor decks usually count downloads or revenue. ASTP/ONC measures something different: whether individuals accessed their own records.

Remote Patient Monitoring: Build With Guardrails

Remote patient monitoring has the widest gap between vendor enthusiasm and independent scrutiny.

What the independent data shows

In September 2024, the HHS Office of Inspector General reported that Medicare use of remote patient monitoring grew sharply between 2019 and 2022. About 43% of enrollees who received it did not get all three components: the device, setup and education, and treatment management (OIG report). OIG also said Medicare lacked key oversight information, including who ordered the monitoring.

OIG recommended safeguards such as requiring an ordering provider on claims and monitoring companies that specialize in RPM. It also expects growth to continue, since many Medicare enrollees have conditions that monitoring can track.

What vendors claim

Platform vendors cite outcome improvements and cost savings, often from vendor-sponsored studies. Check who sponsored any study a vendor quotes.

OIG's review tests whether patients received the service Medicare was billed for. It doesn't measure clinical outcomes, so outcome claims need their own independent evidence. For software teams, the OIG findings are the ones that shape product requirements.

What is worth building?

• Ordering-provider capture and display for every monitored patient.
• Device-to-EHR integration that writes readings into the chart.
• Audit trails that log setup, patient education, device data transmission, and clinician review.
• Onboarding flows that record education and consent.
• Escalation rules that route out-of-range readings to a named clinician.

These features serve patients and compliance at once. If CMS adopts OIG's recommendations, products that already log this information will adapt faster. Check current CMS reimbursement rules for your target codes before you commit, since coverage terms change.

What counts as hype

An RPM platform pitch with no escalation path, no clinical owner, and no audit trail deserves skepticism. A dashboard of readings nobody reviews is a billing risk. We'd decline to build one without a clinical workflow behind it.

Cloud Migration: Plan in Phases

Cloud migration is the oldest of the four trends, and the data shows it's still unfinished.

What health systems have done

A July 2025 KLAS Research report found that more than 80% of healthcare organizations use a public cloud provider, yet only one of the 36 health systems and hospitals interviewed has moved its infrastructure fully to the cloud, according to Becker's summary of the KLAS report. Azure was the most common primary provider, followed by AWS. Many respondents plan to speed up migration within one to two years.

What to migrate first

• Analytics and reporting workloads.
• Interoperability and integration middleware, including FHIR facades and API gateways.
• New patient-facing services.
• Backup and disaster recovery.

What can wait?

Core clinical systems with deep legacy dependencies can wait for a second phase with a cost model. A lift-and-shift without that model moves the same workloads to a new invoice.

Compliance checklist

Confirm these with your compliance team before any workload moves:

• A HIPAA business associate agreement with the cloud provider.
• Data residency and access logging requirements.
• Encryption at rest and in transit.
• An audit trail for access to protected health information.
• Disaster recovery tests on a schedule.

Build, Wait, or Skip: The 2027 Decision Table

The table below pulls the four verdicts together. Each row pairs the strongest independent evidence with the vendor claim it should be checked against.

Trend	Verdict	Strongest independent evidence	Common vendor claim	First step
FHIR and interoperability	Build now	CMS-0057-F deadline of January 1, 2027; 70% of hospitals enabled FHIR-based app access in 2024 (ASTP/ONC)	"FHIR is solved"	Map payer API connections and build a facade over existing systems
Patient-facing apps	Build selectively	87% portal use when clinicians encourage it versus 57% when they don't; 7% use aggregator apps (ASTP/ONC)	Download and market-size figures	Add features inside existing clinical workflows
Remote patient monitoring	Build selectively, with guardrails	43% of Medicare enrollees missed a service component (HHS OIG)	Outcome and savings claims from sponsored studies	Build ordering-provider capture and audit trails first
Cloud migration	Build selectively, in phases	1 of 36 health systems fully migrated (KLAS)	Cloud-first targets and projected migration rates	Move analytics and integration workloads first

 

How to Sequence the 2027 Roadmap

The only fixed date belongs to interoperability, so the rest of the plan can build around it.

• Q4 2026: Ask each major payer in writing for its API implementation plan and developer onboarding process.
• Q1 2027: Finish FHIR work for the January deadline, or test connections to payer APIs as they go live.
• Spring 2027: Add patient app features that use the new payer data, such as prior authorization status.
• Mid-2027: Pilot remote monitoring with audit trails, and start moving analytics and integration workloads to the cloud.

Three baseline questions before you spend

1. Which payers drive most of your prior authorization volume?
2. Which app features do clinicians already point patients to?
3. Which workloads have a cost model for the cloud?

Conclusion: Where to Spend the 2027 Budget

Interoperability has a date, which makes it the easiest decision of the four. Patient apps, remote monitoring, and cloud migration each have evidence behind specific uses and thinner evidence behind the broad claims.

The pattern repeats across all four. Adoption figures describe capability, usage, or plans, and those three rarely match. Check which one a number measures before it enters a business case.

What to fund first

Fund the dated requirement first, because a missed deadline costs more than a late pilot. Put the next dollars into work that serves more than one trend, such as a FHIR layer that also feeds patient apps and an integration tier hosted in the cloud.

Pilot the rest with a stop rule. Set the baseline, the review date, and the number that ends the pilot before it starts.

Predictions for 2027 and beyond

These predictions are our own reading of the evidence above, and none of them comes from the cited sources. Treat them as hypotheses to test.

Payer APIs will launch unevenly, and usage will lag availability. We expect many payers to meet the January 2027 date with a FHIR layer over existing systems. CMS already requires payers to report Patient Access API usage metrics, so the gap between availability and use will become measurable. The hospital data suggests the first figures will show it.

Demand will shift to the provider side. Once payer APIs are live, the open work is connecting them to clinical workflows. We expect connector and workflow projects to make up a growing share of interoperability work.

Payer data will become the differentiator in patient apps. Prior authorization status and claims data will reach patients through the new Patient Access API. Apps that put that data next to a clinician's recommendation will have a stronger case than standalone aggregators, which still sit at 7% use.

Remote monitoring will face stricter documentation. OIG's recommendations point toward ordering-provider data and better service tracking on claims. We expect programs without clear audit trails to struggle and products that log setup, education, and review to gain ground.

Cloud will end up hybrid for most health systems. KLAS found that 35 of 36 respondents still run some on-premises infrastructure, and many plan to speed up migration. We expect analytics and integration workloads to move first, with core clinical systems following on longer timelines.

AI features will arrive through the same data pipes. Summarization, triage, and prior authorization automation all need clean, standards-based data. Teams that finish the FHIR and cloud groundwork will be able to add those features sooner.

Signals to watch

Five signals will show quickly whether these predictions hold:

• The annual public prior authorization metrics payers publish by March 31, and the Patient Access API usage metrics they report to CMS.
• The next ASTP/ONC data briefs on hospital API and patient app use.
• Any CMS action on OIG's remote monitoring recommendations.
• The next KLAS update on cloud migration plans versus completed moves.
• Your own baselines from the three questions above.

Revisit the plan each time one of these arrives, and move budget toward the trend the new numbers support.

FAQs

• What does CMS-0057-F require by January 2027?

  Impacted payers must have Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs in production, generally by January 1, 2027. The rule covers Medicare Advantage organizations, Medicaid and CHIP programs, and qualified health plan issuers on the federally facilitated exchanges. Prior authorization decision timeframes and public reporting started earlier, in 2026.

• Do healthcare providers need to build FHIR APIs under this rule?

  No. The API requirements apply to payers. Providers benefit from building connectors that consume those APIs inside clinical workflows.

• Are patient-facing apps worth building in 2027?

  Yes, when they sit inside a care workflow. ASTP/ONC data shows 87% portal use among people whose clinician encouraged it, compared with 57% among those who weren't encouraged. Standalone apps and record aggregators have weaker evidence, with 7% of individuals using an aggregator app.

• Is remote patient monitoring worth building?

  It is worth building with guardrails. HHS OIG found that 43% of Medicare enrollees receiving monitoring did not get all three service components, and it recommended stronger oversight. Ordering-provider capture and audit trails prepare a product for tighter rules.

• Should hospitals migrate fully to the cloud?

  KLAS found that more than 80% of organizations use a public cloud, but only one of 36 health systems has migrated fully. A phased approach that starts with analytics and integration workloads fits that pattern.