CMS Consolidated Its Health IT Authority Into One Office. Here Is What Actually Lands on Your Desk.

Federal reorganizations are easy to ignore. Most of them are box-moving exercises that change letterhead and nothing else, and if you are the one person responsible for keeping a 25-bed hospital's servers, network, and EHR interfaces alive, you have earned the right to be skeptical of another Federal Register notice.

This one deserves a read anyway. Not because it imposes a new requirement on your organization - it does not - but because the office it created now owns the roadmap for a set of systems your organization touches every single day: Medicare claims processing, the provider enrollment and identifier systems behind your NPIs, the interoperability rules your EHR vendor builds to, and the identity requirements for connecting to federal platforms.

On June 9, 2026, the Secretary of Health and Human Services approved the establishment of the Centers for Medicare & Medicaid Services Office of Health Technology and Products, effective the same day. The notice was published in the Federal Register on June 11 at 91 FR 35478, spanning pages 35478 to 35482 and roughly ninety enumerated functions across eight subordinate components. That is not a footnote. A typical Statement of Organization notice is a page or two.

What the Notice Actually Says

OHTP sits above eight components: an Open Source Program Group; a Standards & Interoperability Group containing a Division of Data and Interoperability Platforms and a Division of Policy; a Product Development Group containing a Division of Core Products and a Division of External Products; and Digital Service at CMS.

The functional list is broad. OHTP is assigned enterprise leadership for CMS health care technology and digital product strategy across Medicare, Medicaid, CHIP, and other CMS-administered programs. It directs modernization and replatforming of Medicare claims and payment systems. It leads product strategy for the National Provider Directory and associated systems including NPPES and PECOS. It runs beneficiary-facing platforms including Medicare.gov and the Medicare Plan Finder. It stewards identity, access, and trust services. It leads enterprise AI strategy across CMS digital products and advises the CMS Administrator on AI opportunities, risks, and governance.

Amy Gleason leads the office as deputy administrator and chief product officer. Worth noting: the Federal Register notice does not name her. That detail came from a CMS spokesperson via Healthcare Dive on June 12. Gleason came up through nursing, co-founded the care coordination company CareSync, served with the U.S. Digital Service, and has driven the CMS Health Tech Ecosystem initiative since its launch.

Here is the part most coverage has glossed over, and it matters if you are trying to figure out who to actually pay attention to. OHTP does not own cybersecurity. The notice is explicit and repetitive on this point: OHTP 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 and investment control responsibilities, along with FITARA approval requirements. The identity and access stewardship language is qualified the same way, aligning to CIO and CISO-led ICAM and zero-trust governance under OMB Memoranda M-19-17 and M-22-09. OHTP sets product direction. The CIO still sets the security floor.

The ONC Split, and Why It Explains This

This did not appear out of nowhere. On March 31, 2026, HHS reversed a 2024 reorganization, dropping the dual ASTP/ONC title and returning the office to simply the Office of the National Coordinator for Health Information Technology. The department-level chief technology officer, chief AI officer, and chief data officer roles moved back under the HHS Office of the Chief Information Officer. ONC retains TEFCA, information blocking enforcement, USCDI, and the certification program.

Put the two changes together and the division of labor is fairly clean. ONC sets standards, certification criteria, and health IT policy. CMS, through OHTP, builds and runs the operational machinery and increasingly writes the interoperability policy that attaches to payment programs. For a rural hospital IT director, the practical translation is that the standards conversation and the payment-consequence conversation now live in two different buildings, and the one with the payment consequences got bigger.

Where This Touches Operations: Claims

The most consequential item in OHTP's portfolio is the one with the longest fuse. CMS is trying 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 been feeding 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 are COBOL and Assembler on IBM mainframes with nightly batch cycles and flat-file history. Collectively they handle roughly 1.2 billion claims and about $460 billion in payments annually. Gleason, speaking at a value-based payment conference in March, put the staffing problem bluntly, noting that COBOL engineers are effectively impossible to find anymore. The 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 numbers were $1.15 billion and $826 million. Read those carefully, because they are ceilings, not checks. Award notices posted to SAM.gov show initial obligations of approximately $2.5 million to HealthEdge and $9.2 million to Peraton, roughly $11.6 million combined. The remainder sits in unexercised options. This is a competitive proof-of-concept structure with both vendors building and demonstrating against real CMS data, and the option value only activates if CMS decides to advance a solution toward production. The solicitation described an initial proof-of-concept period running from May 4 to November 4, 2026. The ultimate completion date on the award is November 2033.

So: nothing changes for your claims submission this year, or next. What you should do is more modest and more useful. Inventory what actually touches Medicare FFS claims in your environment - your clearinghouse, the interface engine, whatever billing module sits between your EHR and the outside world, and any homegrown scripts nobody has looked at since the last upgrade. Know who owns each of those integrations 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 human checking a folder every morning, that is worth knowing now rather than in 2031.

Where This Touches Operations: Provider Data

This is the near-term one, and it is unglamorous.

OHTP's Division of Core Products owns the National Provider Directory along with NPPES and PECOS. If you have ever tried to figure out why a claim rejected on a credentialing issue, you already have opinions about these systems.

PECOS 2.0 is now the primary submission pathway for Medicare enrollment and revalidation. It requires registration through CMS Identity & Access Management with multi-factor authentication, and organizations must designate an Authorized Official in I&A before staff can touch enrollment records. The rebuilt platform performs automated cross-referencing against IRS and NPPES data during submission, which catches mismatches the legacy system let through. That is a genuine improvement and also a new failure mode, because inconsistencies between your NPPES record and your enrollment data that sat harmlessly for years can now surface as an application problem. 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 fixed it in one place, that is a fifteen-minute reconciliation task that is much cheaper to do voluntarily than 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 and for program attribution.

The directory has also had a rough year, and it is worth being straightforward about that. On April 30, 2026, The Washington Post reported that a publicly downloadable database powering the Medicare provider directory contained Social Security numbers belonging to health care providers. Politico subsequently reported at least 102 providers with full unredacted numbers in the file. The data was not visible through the patient-facing search tool but was present in the underlying downloadable dataset, which had been accessible for at least several weeks. CMS took the directory offline after being alerted, attributed the exposure to providers or their representatives entering Social Security numbers into incorrect form fields combined with insufficient validation, and said it had reinforced safeguards around data submission and validation. Senators Ron Wyden and Jeff Merkley sent CMS Administrator Mehmet Oz a list of questions about the incident on May 20.

No external attacker was involved. That is precisely why it is instructive. A form field without input validation, feeding a public dataset, is the same failure pattern that shows up in health care organizations constantly - the intake form that accepts anything, the export that includes columns nobody audited, the report that got shared more widely than intended. If your organization submits provider data to any federal or payer system, it is a reasonable afternoon's work to confirm what fields you populate, what validation exists on your side, and whether anyone has ever reviewed what leaves your building.

The One Hard Deadline

Everything above is directional. This one has a date and a payment consequence attached.

The CMS Interoperability and Prior Authorization final rule (CMS-0057-F), published January 17, 2024, requires impacted payers - 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 already took effect on January 1, 2026, including decision turnaround times of 72 hours for expedited requests and seven calendar days for standard requests, along with specific denial reasons.

The provider-side hook is the part small hospitals need to have on their radar. CMS-0057-F adds an Electronic Prior Authorization measure under the Health Information Exchange objective in both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. Eligible hospitals and Critical Access Hospitals report it beginning with the CY 2027 EHR reporting period. It is an attestation measure, yes or no, with exclusions available - CMS backed away from its proposed numerator and denominator approach.

But the failure mode is sharp. Per 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 Critical Access Hospital, that is not a rounding error.

The action item is simple and you should do it this quarter: ask your EHR vendor, in writing, what their Prior Authorization API roadmap is and what version or module you will need to be on by January 2027 to attest yes. Ask whether it costs extra. Get the answer in email. CMS maintains guidance for providers at cms.gov/priorities/electronic-prior-authorization, and asking your vendor now is considerably better than discovering in late 2027 that the capability lives in a licensing tier you do not have.

Identity, AI, and the HIPAA Angle

OHTP's identity stewardship mandate points toward stronger identity proofing and phishing-resistant authentication for anyone 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. The direction of travel is unambiguous even where the specifics are not yet binding on providers.

For AI, OHTP now holds enterprise strategy across CMS digital products. If you are 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 issues becomes a legitimate due-diligence question. Ask it during procurement rather than after.

Two HIPAA points are worth naming, briefly, because this is the kind of change that quietly invalidates documentation. 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 ePHI is not accurate if it describes an architecture you no longer run. 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 or other arrangement implementation specification at 164.308(b)(3) is Required. That contract has to meet the requirements at 45 CFR 164.314(a). "The EHR vendor is handling it" is not a business associate agreement.

What to Watch

Track Federal Register notices and CMS.gov postings originating from OHTP's Division of Policy, which holds the mandate to develop and promulgate interoperability policy, regulations, and sub-regulatory guidance. Watch for ClaimsCore phase decisions, since the proof-of-concept structure means a production vendor selection is a real inflection point. Watch NPPES file format and NPD API changes, and any updated technical specifications for provider enrollment. And watch whether OHTP publishes AI governance guidance, because that will shape vendor claims quickly.

One measured note on the Health Tech Ecosystem, which is the initiative OHTP was substantially built to support. At a one-year event on July 27, 2026, HHS said the program had grown from just over 60 initial companies to more than 800 pledges, and announced new voluntary pledge categories covering price transparency, clinical trial matching, scheduling, bulk FHIR population health exchange, pharmacy interoperability, and real-time benefits access. HHS chief counselor Chris Klomp said 60 percent of patients can now access their records through an app of their choice, up from 5 percent a year prior, with a projection of 80 percent by October. Nextgov reported that HHS did not explain the methodology behind those figures. Treat them as directional claims from an agency describing its own program, not as verified market data. The pledges remain voluntary and carry no regulatory force.

The honest summary is this. OHTP is a real consolidation of federal health IT execution authority, and the office now owns product direction for infrastructure that essentially every U.S. health care organization depends on. But it is a consolidation of direction, not a new set of mandates, and its practical effect on your organization over the next eighteen months arrives almost entirely through two channels: updated technical specifications from systems you already interface with, and the CMS-0057-F deadlines that were already on the books.

Do the provider data reconciliation. Email your EHR vendor about the Prior Authorization API. Update your risk analysis when something actually changes. That is the work. The org chart will sort itself out.

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.