Internet Explorer retired; its clinical applications did not
IE mode in Edge let hospitals keep legacy web applications running after the old browser’s retirement. The compatibility list it required was a ready-made inventory of legacy risk, best worked down by who could fix each site: the hospital, its vendors, or outside parties.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On June 15, 2022, Microsoft retired the Internet Explorer 11 desktop application on most supported versions of Windows 10, ending support for a browser that had shipped with Windows since the 1990s. For sites that still needed it, Microsoft pointed organizations to Internet Explorer mode in Microsoft Edge. It renders listed sites with the legacy engine inside the modern browser, and Microsoft committed to support it through at least 2029. The retirement had been announced in May 2021. It happened in phases: users were first redirected to Edge, and an Edge update in February 2023 permanently disabled the old desktop application on affected systems. Some Windows editions, including certain long-term servicing versions, were outside the June 2022 retirement.
Few sectors had more riding on this retirement than health care. Over two decades, hospitals and health plans accumulated web applications built for Internet Explorer: departmental clinical systems, scheduling tools, imaging viewers, lab and pharmacy interfaces, device management consoles, payer portals and state registry sites. Many relied on ActiveX controls, old document modes or Java applets that no modern browser supports.
IE mode solved the immediate problem well. Staff browse in a modern browser, and only sites an administrator places on an enterprise site list open with the legacy engine. That shrank a large attack surface, because staff were no longer reading general web content with an engine that would soon receive no fixes. It also produced something many health systems had never had: a single, authoritative list of every web application that still depended on old technology.
The risk was that the list would become permanent. A site in IE mode still runs old code, often with old authentication and unmaintained plug-ins, on a dated engine. The browser around it is new. The application is not. Working the list down required sorting each entry by who could actually fix it, because the remedy differs completely for applications the hospital owns, products its vendors supply, and portals run by outside parties.
Applications the hospital owns
The first group is internal: departmental tools written by hospital developers or long-departed contractors, intranet forms, reporting pages and small databases with web front ends. These are the hospital’s to fix, and also the easiest to neglect, because no vendor will ever send a reminder.
Each needs a decision: rewrite, replace with a feature of an existing platform, or retire. A surprising number can be retired. Usage logs from the site list often show applications opened by a handful of people, or not at all. Others duplicate functions now available in the electronic health record or a standard workflow tool. The remainder justify a small modernization budget, prioritized by clinical importance and by how outdated the authentication is.
Authentication deserves its own review. Legacy internal applications frequently use local accounts, shared logins or integrated Windows authentication without multi-factor protection. Folding them into the hospital’s single sign-on, or retiring them, closes gaps that a browser project alone would not touch.
Ownership is the other gap. Many internal tools have no current business owner, only a server and a URL. Assigning each surviving application to a named department head, who confirms each year that it is still needed, prevents the list from refilling. It also gives the modernization budget a sponsor who can explain the clinical or operational case for the money.
Products the vendors supply
The second group is vendor software: clinical and departmental systems, device management consoles, and administrative products whose web interfaces were built for Internet Explorer. The hospital cannot fix the code, but it can use the contract.
For each product, the useful questions are concrete. The first is whether a version exists that runs in a modern browser. If it does, the hospital needs to know what the upgrade requires, such as new licenses, new servers or revalidation of clinical workflows. If it does not, the vendor should give a committed date and say what happens to support if the date slips. The answers belong in the vendor management file and in renewal terms. A renewal is when the hospital has the most bargaining power, and a clause that ties continued payment to a modern-browser release by a set date focuses attention.
Medical device consoles are the hardest case. A console tied to imaging or lab equipment may only be upgradeable along with the hardware, which has a long service life and a capital budget of its own. Those entries should be linked to the device replacement plan and isolated on the network in the meantime, with access limited to the clinical engineering staff who need it.
Portals outside parties run
The third group is external: payer portals for eligibility and prior authorization, state immunization and disease reporting sites, and some partner systems. Staff use them daily, and the hospital controls none of them.
The options here are indirect. Report the dependency to the portal owner through account managers, provider relations or industry associations, since one hospital’s complaint carries less weight than a group’s. Avoid building new workflows around portals that still require the legacy engine. Where an alternative exists, such as an electronic data interchange transaction or an interface that replaces manual portal entry, prefer it. That often improves efficiency as well as removing the browser dependency.
External entries also need a contingency plan. If a portal stops working in IE mode, or Microsoft eventually ends IE mode, staff need another route to complete eligibility checks or required reporting. Knowing in advance which portals have a phone, fax or file-based fallback prevents a scramble.
Across all three groups, the site list doubles as a management metric. Its length, broken down by owner category and clinical importance, gives leadership a plain measure of legacy exposure. A list that shrinks every quarter shows a program working. One that stays flat shows that the compatibility layer has quietly become the plan.
With hindsight
The phased retirement went as Microsoft described, and the February 2023 Edge update removed the old desktop application from affected systems. IE mode has remained available, and many health systems still keep a site list in 2026, though most are much shorter than in 2022. Clinical and administrative software vendors have, in many cases, shipped browser-neutral versions, often as part of moves to cloud delivery. The entries that remain tend to be the ones this framing predicts: device consoles tied to long-lived hardware, small internal tools with no budget, and external portals the hospital cannot change. The end of Windows 10 support in October 2025 forced another round of legacy cleanup, and teams that had already worked their IE list found that work easier. Microsoft’s commitment to support IE mode through at least 2029 still sets the outer horizon.