CMS Created a New Health Technology Office. Here Is What It Means for Critical Access Hospitals.

Federal reorganizations rarely earn a spot on anyone's task list, and for a rural hospital IT department that is often one or two people, that instinct is usually correct. Most of them move boxes on an org chart and change nothing about the work.

This one is worth ten minutes anyway, not because it creates a new requirement for your organization, but because the office it created now sets product direction for systems your organization depends on every day: Medicare claims processing, provider enrollment and identifier systems, interoperability policy that your EHR vendor builds toward, and identity requirements for connecting to federal platforms.

We work exclusively with rural health care organizations, and the pattern we see with announcements like this one is predictable. Nothing appears to change, so nothing gets reviewed, and then a deadline that was published two years earlier turns into a scramble. This article separates what is directional from what has an actual date attached, and what a small IT team should do about each.

What Actually Happened

On June 9, 2026, the Secretary of Health and Human Services approved establishment of the Centers for Medicare & Medicaid Services Office of Health Technology and Products (OHTP), effective the same day. The Statement of Organization was published in the Federal Register on June 11, 2026 at 91 FR 35478.

OHTP consolidates eight subordinate components, including a Standards and Interoperability Group, a Product Development Group, an Open Source Program Group, and Digital Service at CMS. Its assigned functions include enterprise leadership for CMS health care technology and digital product strategy across Medicare, Medicaid, and CHIP; modernization of Medicare claims and payment systems; product strategy for the National Provider Directory, NPPES, and PECOS; beneficiary-facing platforms including Medicare.gov; identity, access, and trust services; and enterprise AI strategy across CMS digital products.

Amy Gleason leads the office as deputy administrator and chief product officer.

What OHTP Does Not Own

This distinction gets lost in most coverage, and it matters for anyone trying to figure out whose guidance to actually follow.

OHTP does not own cybersecurity. The Federal Register notice states repeatedly that the office operates in close coordination with the CMS Chief Information Officer and remains subject to CIO-led enterprise IT governance, cybersecurity, enterprise architecture, and capital planning responsibilities. The identity and access stewardship language is qualified the same way, aligning to CIO and CISO-led identity, credential, and access management and zero-trust governance under OMB Memoranda M-19-17 and M-22-09.

In practical terms: OHTP sets product direction. The CMS CIO still sets the security floor.

This also arrives alongside a related change. On March 31, 2026, HHS reversed a 2024 reorganization and returned the Office of the National Coordinator for Health Information Technology to its original name and structure, moving department-level technology, AI, and data officer roles back under the HHS Office of the Chief Information Officer. ONC retains TEFCA, information blocking enforcement, USCDI, and the certification program.

The resulting division of labor is reasonably clean. ONC sets standards and certification criteria. CMS, through OHTP, builds and operates the machinery and increasingly writes the interoperability policy that attaches to payment programs. For a Critical Access Hospital, that means the standards conversation and the payment consequence conversation now live in two different places, and the one with payment consequences got larger.

The One Item With a Hard Deadline

Everything above is directional. This is not.

The CMS Interoperability and Prior Authorization final rule (CMS-0057-F), published January 17, 2024, requires impacted payers, including Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and Qualified Health Plan issuers on the federally facilitated exchanges, to implement a Prior Authorization API, Provider Access API, and Payer-to-Payer API, with compliance generally required by January 1, 2027. Operational provisions took effect January 1, 2026, including prior authorization decision turnaround times of 72 hours for expedited requests and seven calendar days for standard requests.

The provider-side hook is the part small hospitals need on their radar. CMS-0057-F adds an Electronic Prior Authorization measure under the Health Information Exchange objective in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. Eligible hospitals and Critical Access Hospitals report it beginning with the CY 2027 EHR reporting period.

It is a yes or no attestation, and exclusions are available. CMS did not finalize its proposed numerator and denominator approach. The failure mode, however, is sharp: under the final rule, an eligible hospital or CAH that reports "no" and does not claim an applicable exclusion is not considered a meaningful EHR user and fails to meet minimum program reporting requirements.

For a 25-bed hospital operating on thin margins, that is not a paperwork problem.

What to do this quarter: Email your EHR vendor and ask, in writing, what their Prior Authorization API roadmap is, what version or module you need to be running by January 2027, and whether the capability carries additional licensing cost. Keep the reply. Discovering in late 2027 that the functionality lives in a licensing tier you do not have is a considerably worse conversation than having it now. CMS maintains provider guidance on electronic prior authorization at cms.gov.

Provider Enrollment Data: The Near-Term, Unglamorous One

OHTP's Division of Core Products owns the National Provider Directory along with NPPES and PECOS. If your business office has ever chased down a claim rejection tied to a credentialing mismatch, these are the systems responsible.

PECOS 2.0 is now the primary submission pathway for Medicare enrollment and revalidation. It requires registration through CMS Identity and Access Management with multi-factor authentication, and organizations must designate an Authorized Official in I&A before staff can work on enrollment records. The rebuilt platform performs automated cross-referencing against IRS and NPPES data at submission, which catches mismatches the legacy system allowed through.

That is a genuine improvement and also a new failure mode. Inconsistencies between your NPPES record and your enrollment data that sat harmlessly for years can now surface as an application problem, and updates made in NPPES do not automatically propagate to PECOS. If your organization has changed a practice location, a legal business name, or a taxonomy code and only corrected it in one system, that reconciliation is a short task on your schedule and a long one under a revalidation clock.

The National Provider Directory itself is live in beta at directory.cms.gov as a FHIR-based API layer sitting alongside NPPES rather than replacing it. NPPES remains the operational source of truth for NPI assignment.

The directory also had a rough spring, and the lesson is worth taking even though the incident was not yours. On April 30, 2026, The Washington Post reported that a publicly downloadable dataset behind the Medicare provider directory contained Social Security numbers belonging to health care providers. The data was not visible through the patient-facing search tool but was present in the underlying file. CMS took the directory offline, attributed the exposure to numbers entered into incorrect form fields combined with insufficient validation, and said it reinforced safeguards around data submission and validation.

No attacker was involved, which is exactly why it is instructive. Provider Social Security numbers are not protected health information, but the failure pattern applies equally to data that is: an intake form that accepts anything, an export that includes columns nobody audited, a report shared more broadly than intended. If your organization submits provider data to federal or payer systems, confirming what fields you populate, what validation exists on your side, and who has ever reviewed what leaves your building is an afternoon's work.

Medicare Claims Modernization: Long Fuse, Short Homework

The largest item in OHTP's portfolio is also the slowest. CMS is working to replace the core of Medicare fee-for-service claims processing under a program called ClaimsCore.

The systems in scope are the ones your billing staff and clearinghouse have fed for decades: the Fiscal Intermediary Shared System for institutional Part A claims, the Multi-Carrier System for professional Part B, the DME claims system, and the Common Working File. They run on IBM mainframes in COBOL and Assembler with nightly batch cycles, handling roughly 1.2 billion claims and about $460 billion in payments annually. CMS solicitation documents describe policy changes taking seven to twelve months to implement in code.

On May 29, 2026, CMS awarded firm-fixed-price contracts to HealthEdge Software and Peraton. The headline ceiling values were $1.15 billion and $826 million, but award notices posted to SAM.gov show initial obligations of roughly $2.5 million and $9.2 million respectively, with the remainder in unexercised options. This is a competitive proof-of-concept structure, with an initial period described as running from May 4 to November 4, 2026, and an ultimate completion date in November 2033.

Nothing changes for your claims submission this year or next. The useful work is smaller and more immediate. Inventory what actually touches Medicare fee-for-service claims in your environment: your clearinghouse, your interface engine, the billing module between your EHR and the outside world, and any homegrown scripts nobody has opened since the last upgrade. Know who owns each integration and what your contract says about the vendor's obligation to keep pace with CMS specification changes.

The target architecture in the solicitation contemplates sub-second adjudication and real-time claims status delivered over both HIPAA X12 and FHIR/REST APIs. If your billing pipeline is a batch process with a staff member checking a folder every morning, that is worth knowing now rather than in 2031. Interface documentation is also one of the first things to disappear when the person who built the integration retires, which is a separate problem that this deadline happens to expose.

Identity and AI: Direction, Not Requirement

OHTP's identity stewardship mandate points toward stronger identity proofing and phishing-resistant authentication for organizations connecting to CMS platforms. The CMS Interoperability Framework already describes identity assurance at IAL2 and authenticator assurance at AAL2 for patient-directed access using approved credentials. None of that is binding on providers today, but the direction of travel is not ambiguous, and organizations still running shared accounts or SMS-based second factors for administrative access to federal systems should treat that as a known gap rather than a surprise.

On artificial intelligence, OHTP now holds enterprise strategy across CMS digital products. If your organization is evaluating an AI-assisted revenue cycle tool, coding assistant, or documentation product that touches Medicare or Medicaid data, the vendor's posture toward whatever governance framework OHTP eventually issues is a legitimate procurement question. Ask it before signing, not after.

Where HIPAA Documentation Quietly Falls Out of Date

This is the part that catches organizations, and it has nothing to do with the reorganization itself.

If your organization stands up new API endpoints, federates identity with an external platform, or changes how provider or patient data moves in or out, that is a change to your environment. The risk analysis requirement at 45 CFR 164.308(a)(1)(ii)(A) is a Required implementation specification, and an accurate and thorough assessment of risks to electronic protected health information is not accurate if it describes an architecture you no longer run. Incomplete or stale risk analysis is among the most frequently cited findings in OCR enforcement actions.

Second, if a new vendor or intermediary creates, receives, maintains, or transmits ePHI on your behalf as part of any of this, the business associate contracts standard at 45 CFR 164.308(b)(1) applies, and the written contract implementation specification at 164.308(b)(3) is Required. That contract must meet the requirements at 45 CFR 164.314(a). An assurance that the EHR vendor is handling it is not a business associate agreement.

The Short Version for Small IT Teams

For a Critical Access Hospital, Rural Emergency Hospital, or Rural Health Clinic with limited IT staff, the practical scope of this reorganization over the next eighteen months comes down to four things:

• Email your EHR vendor about the Prior Authorization API. Get the roadmap, the required version, and the licensing answer in writing. CY 2027 is the reporting period.
• Reconcile NPPES and PECOS. Practice locations, legal business names, and taxonomy codes. Voluntarily, not under a revalidation clock.
• Inventory your claims and interface path. Every system between your EHR and Medicare, who owns it, and what the contract says about specification changes.
• Update your risk analysis when the environment actually changes. New endpoints, new identity federation, and new data flows all qualify.

What to Watch

Federal Register notices and CMS.gov postings originating from OHTP's Division of Policy, which holds the mandate for interoperability policy, regulation, and sub-regulatory guidance. ClaimsCore phase decisions, since a production vendor selection would be a real inflection point. NPPES file format and National Provider Directory API changes. And whether OHTP publishes AI governance guidance, because vendor claims will follow it quickly.

The honest summary is that OHTP represents a meaningful consolidation of federal health IT execution authority, and the office now sets direction for infrastructure nearly every U.S. health care organization depends on. But it is a consolidation of direction, not a new set of mandates. Its practical effect on your organization arrives through two channels: updated technical specifications from systems you already interface with, and the CMS-0057-F deadlines that were already on the books.

visuaFUSION Systems Solutions is a managed IT and Microsoft licensing provider working exclusively with rural health care organizations, including Critical Access Hospitals, Rural Emergency Hospitals, Rural Health Clinics, and small community hospitals. A large share of what we do is exactly this kind of translation work: reading what a federal change actually requires, separating it from what it does not, and making sure the environment and the documentation still match each other when someone asks. For organizations running on one or two IT staff, that operational continuity is usually the difference between a scheduled task and an emergency.

Leveling the IT Playing Field for Rural Health Care Organizations.

Reviewed by visuaFUSION health care IT professionals with experience supporting Critical Access Hospitals and Rural Health Clinics.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

• Centers for Medicare & Medicaid Services, "Statement of Organization, Functions, and Delegations of Authority," 91 FR 35478, June 11, 2026 (FR Doc. 2026-11743). federalregister.gov
• CMS, "CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)," published January 17, 2024, fact sheet and final rule text. cms.gov
• CMS, "Electronic Prior Authorization" provider guidance. cms.gov/priorities/electronic-prior-authorization
• CMS, National Provider Directory (beta). directory.cms.gov
• CMS, "Interoperability Framework," Health Technology Ecosystem. cms.gov
• SAM.gov award notices, ClaimsCore, posted June 1, 2026: Peraton Inc., Award ID 75FCMC26C0014; HealthEdge Software, Inc., Award ID 75FCMC26C0015. Solicitation Notice ID 75FCMC26R0022.
• The Washington Post, "Medicare portal exposed health providers' Social Security numbers," April 30, 2026.
• FedScoop, "HHS reverses Biden-era reorganization of top AI, data, tech roles," March 31, 2026.
• Healthcare Dive, "CMS creates office dedicated to health technology," June 12, 2026.
• 45 CFR Part 164, Security Standards for the Protection of Electronic Protected Health Information. ecfr.gov