Interoperability’s next test is whether smaller hospitals can keep up
National standards will not close the gap if rural, critical-access and independent hospitals lack the staff, capital and time to implement them.
Interoperability is often described as a process of removing barriers. Establish common standards, open the networks, publish the implementation guides and give organizations a path to participate. That work matters, and it has moved the industry forward, but an open path is not necessarily an accessible one.
The provider voices most visible in national technology discussions often come from large academic institutions and integrated health systems. Those organizations can bring capital, policy expertise, interface teams and staff time to workgroups that smaller organizations may not have. Rural, community and independent hospitals operate under very different conditions, where the same analysts responsible for interoperability may also be keeping core systems running, troubleshooting interfaces and supporting daily care.
That creates a risk at an otherwise hopeful moment. The first article in this series argued that interoperability is finally moving from data exchange toward data utility; the second showed how electronic prior authorization can fail if technically conformant APIs do not fit real workflows. The final test is whether those advances can be implemented by organizations with the least discretionary capacity rather than only by those able to move first.
A seat at the table still carries a price
Formal barriers to interoperability participation are lower than they once were. FHIR provides a common technical foundation, TEFCA offers a nationwide exchange framework and public workgroups give more organizations ways to influence implementation. Meaningful participation, however, still requires scarce resources: time to read proposals, attend meetings, test specifications, interpret policy, assess risk and explain the implications internally.
When a small health system is absent from that process, its absence should not automatically be read as lack of interest. It may be evidence of the same capacity problem the process needs to solve. The organizations least able to sit through another national standards call may be the ones most affected by assumptions about staffing, timelines and infrastructure.
Federal data make that difference visible. A 2025 hospital survey summarized by ASTP/ONC found that 43% participated in TEFCA and another 37% planned to participate, bringing the combined current-or-planned share to 80%. Participation and intent were not evenly distributed, however: only 63% of Critical Access Hospitals were participating or planning to participate, compared with 87% of non-CAHs; among independent hospitals, the comparable figure was 54%, versus 92% among multi-hospital system members.
Those differences matter because they reveal more than awareness of a federal framework. They show how system affiliation and organizational scale can influence whether a hospital has the staff, vendor support and strategic bandwidth to move from interest to implementation. A national average can therefore look reassuring while masking exactly the organizations that may need the most implementation support.
The same pattern appears in patient-facing API capabilities. In 2024, 70% of hospitals reported enabling access through FHIR-based apps, but the rate was 56% among independent hospitals versus 76% among system-affiliated hospitals. Critical Access Hospitals reported 64% adoption compared with 72% among non-CAHs, and rural hospitals reported 66% compared with 72% among urban hospitals.
The progress is real, but its distribution is uneven. That is the equity challenge for the next phase of interoperability: not simply whether the standard exists, but whether organizations with different staffing and capital profiles can put it into reliable daily use.
Implementation is a stack, not a switch
A policy may call for an API, a network connection or access to data at scale, and on paper that requirement can look like a defined technical task. Inside a provider organization, implementation sits on top of a much larger stack of infrastructure, governance and labor.
There may be cloud or hardware capacity to procure, databases to tune, identity and security controls to configure, interfaces to test, workflows to redesign and staff to train. Someone still has to monitor the connection, handle exceptions, install upgrades, investigate failures, interpret changing policy and decide who accepts operational and compliance risk. None of that disappears because the specification itself is sound.
MEDITECH manager of interoperability development Jason Vogt has described the same distinction through his work with national interoperability groups: availability is not the same as deployability. In interviews for this series, he has emphasized the need to test not only whether technology functions as specified, but whether organizations with smaller teams can implement and maintain it without creating an unsustainable operating burden.
Bulk data exchange illustrates the point. An implementation guide can be technically correct while a receiving environment is not prepared to process large numbers of records, reconcile identities, manage throughput or investigate exceptions at the necessary scale. Building that capability takes development time, and maintaining it takes provider time and money. A solution that effectively requires a dedicated analyst may work well and still be out of reach for a hospital whose entire interface team consists of one or two people.
Functionality is therefore only the first test. Deployability and sustainability matter just as much if interoperability is intended to operate as national infrastructure rather than as a capability available mainly to organizations with a deep technical bench.
Underrepresentation becomes a design constraint
The people who can remain at the table help shape how implementation works. They influence use cases, testing conditions, exception handling and the tradeoffs that eventually become part of the final guide. That is not a criticism of large health systems; the industry needs their technical expertise and willingness to pilot new approaches. The risk arises when the process hears primarily from organizations with enough discretionary capacity to participate continuously.
Assumptions can then become invisible. A testing plan may assume dedicated interface staff, a workflow may assume centralized governance and a deployment timeline may assume ready access to capital, legal review, cybersecurity expertise or scalable infrastructure. Each assumption may be reasonable in one environment and prohibitive in another, which means representation is not just an equity concern; it is a design input.
Technology developers and industry associations can help carry the experience of smaller customers into national forums, especially when those customers cannot attend consistently. MEDITECH, for example, participates in interoperability and rural-health policy groups and uses webinars, regulatory updates and customer forums to share what it learns. Because this article is written by a MEDITECH executive, that example should be read as one vendor’s approach rather than evidence that vendor representation alone solves the participation problem.
Representation by proxy should not be the only mechanism. Policymakers and standards leaders can also use targeted listening sessions, asynchronous comment channels, implementation pilots in lower-resourced environments and feedback processes that distinguish lack of capacity from lack of interest. If rural and independent organizations are asked to react only after the major design decisions are settled, the most important constraints may already be embedded in the model.
Apply a capacity test before calling a model ready
Every major interoperability initiative should be evaluated against a practical capacity test before it is treated as ready for national scale. The first dimension is representation: were rural, Critical Access, community and independent organizations involved early enough to influence the design, or were they asked to respond only after the operating assumptions were largely fixed?
The second dimension is deployment. Leaders should ask whether a team with one or two analysts can implement the capability within a realistic window without becoming permanently dependent on outside consultants, and whether the required infrastructure assumptions are explicit enough to identify organizations that will need additional support. Computing capacity, connectivity, identity services, cybersecurity tools, testing environments and vendor upgrade cycles should be treated as part of the deployment model rather than as invisible prerequisites.
The third dimension is operations. A capability is not sustainable until someone owns monitoring, exceptions, education, upgrades and policy interpretation after go-live, and those responsibilities have to fit the staffing reality of the organization receiving the technology. A model that depends on continuous specialist attention may be appropriate for some organizations but should not be described as broadly scalable without a shared-service or support strategy.
The fourth dimension is measurement. Adoption and use should be examined by hospital size, rurality, Critical Access status and system affiliation so an overall average does not conceal a widening implementation gap. These questions do not lower the technical bar; they tell us whether the model is actually ready to function across the range of organizations expected to use it.
Capacity support is becoming part of rural transformation
Healthcare now has an opportunity to pair policy ambition with capacity support rather than treating implementation burden as someone else’s problem. The $50 billion Rural Health Transformation Program is state-led, so individual hospitals do not receive a uniform federal interoperability benefit, but CMS has made technology modernization, workforce development and technical assistance central parts of the program’s implementation strategy.
Recent CMS-funded state projects show what that support can look like in practice. South Dakota received $90 million for rural IT modernization, cybersecurity and interoperability; Mississippi’s implementation includes technical assistance, training, interoperable EHRs and cybersecurity enhancements; and South Carolina’s awards include EHR modernization, remote monitoring and cybersecurity upgrades. Those examples do not guarantee that every state will fund the same activities, but they demonstrate that implementation capacity is being treated as an eligible and necessary part of rural transformation rather than as an unfunded afterthought.
Funding alone, however, will not solve representation or operating burden. Capital investments need to be paired with practical implementation assistance, reusable testing tools, realistic deployment windows, shared services and education that reaches the people responsible for operating the technology after go-live. Otherwise, a new interface or platform can become another obligation for the same small team that was already struggling to keep existing systems stable.
Measure reach, not only compliance
It is tempting to define interoperability success by whether an API is available, an implementation guide passes conformance testing or an organization signs a participation agreement. Those milestones matter, but they do not show whether the capability is reliable in daily operations, useful at the point of care or affordable to maintain.
A stronger scorecard would include time to deploy, staff effort required for maintenance, exception volume, actual use and the effect on patients and care teams. It would also ask whether those results differ for a stand-alone rural hospital, an independent practice and a large integrated system. When a gap appears, the response should be part of the implementation strategy rather than deferred to a later equity discussion.
Provider leaders have a role in making those constraints visible. Smaller organizations can surface them through regional coalitions, associations and vendor communities, and they can ask vendors and policymakers to describe the total operational demand of a capability rather than only its technical availability. Larger organizations can help by testing whether workflows and artifacts developed in resource-rich environments remain usable under leaner conditions and by sharing implementation assets that do not need to be reinvented.
I remain optimistic about where interoperability is heading because the industry has more common technical ground than it did even a few years ago. But the finish line is not the moment the best-resourced health system connects first; it is the point at which rural, community and independent organizations can operationalize the same model without pulling the people who keep care running away from their essential work.
That is the final lesson across this three-part series. Interoperability becomes meaningful only when the data are useful, the workflow works and the organization has enough capacity to sustain it. A national model that reaches only the top tier is not yet national in the way that matters.
Mike Cordeiro is Senior Director of Interoperability Market and Product Strategy at MEDITECH, where he focuses on interoperability products and services intended to improve patient and caregiver access to health information.