Hacking and other IT incidents made up more than 80% of the large healthcare data breaches HIPAA Journal tallied from federal breach reports for 2025. Healthcare software maintenance is the routine work that keeps a patient-facing system from becoming one of those entries.
Launch day is when the real cost of a clinical or patient product starts. The systems around it keep changing, and so do the rules it has to follow.
What healthcare software maintenance actually covers
Maintenance is four different kinds of work, and most budgets only plan for one of them. The IEEE Technology Navigator defines them as follows:
- Corrective maintenance addresses faults discovered after release, from urgent patches that restore service to planned fixes in a later version.
- Adaptive maintenance keeps a product operable as its environment changes: operating system upgrades, database migrations, and changes to external APIs.
- Perfective maintenance improves the product beyond its original specification, through user-requested enhancements, updated documentation and efficiency recoding.
- Preventive maintenance finds and repairs latent faults before they cause operational failures.
In healthcare the adaptive category is the one that never stops. A patient portal depends on a cloud provider, a payment gateway, a messaging service and often an EHR, and any of those can change an interface with little notice.
Teams that treat maintenance as bug fixing end up paying for the other three categories as emergencies instead.
Take a forced operating system upgrade on a mobile app that patients use to book visits. Planned, it's a sprint of testing on a quiet week. Unplanned, it arrives as a wave of support tickets while clinicians wait for a fix and nobody has time to test properly.
Preventive work is the easiest to skip because nothing visibly goes wrong when it's done. Its value only shows in the incident that never happens, which makes it a hard line to defend in a budget meeting and an easy one to cut.
Why the security case is the hardest to argue with
A system that stores or moves patient records is a target, and the numbers show it. In the same HIPAA Journal data, the largest 2025 breach was at Conduent Business Services, a business associate, affecting about 62 million people.
That detail matters for maintenance. The exposure sat with a vendor handling data on behalf of healthcare organisations, so your own code being patched isn't the whole picture. Every service your product leans on is part of the surface you answer for.
Unpatched software is a plain, mechanical risk: the longer a known flaw stays open, the longer an attacker has to find it. A maintenance contract is, in practice, a commitment to close those gaps on a schedule instead of when someone happens to notice.
If you're building something new, our guide to HIPAA compliant app development covers the safeguards that go in before launch. Maintenance is what keeps them true afterwards.
What HHS has proposed for scanning, testing and patching
The U.S. Department of Health and Human Services has proposed turning good maintenance habits into written obligations. The Office for Civil Rights issued its notice of proposed rulemaking on December 27, 2024, and, per law firm Baker Donelson's summary, it was published in the Federal Register on January 6, 2025.
It would require vulnerability scanning at least every six months and penetration testing at least once every 12 months. Regulated entities would also need written patch policies and procedures, which the National Law Review reports would be reviewed and tested at least every 12 months, with patching required within timeframes set by risk level.
This is a proposal, and I haven't confirmed whether it has been finalised, so check the current status before building a compliance plan around it. The direction is still useful to plan against. A product with no scheduled scanning and no patch routine will have to build both under pressure if rules like these arrive.
Whatever the final text says, a calendar that already includes scans and an annual test costs little to follow.
Building a maintenance plan that survives contact with reality
A workable plan is short. It names who owns each category of work, how often each is reviewed, and what triggers an out-of-cycle change.
- List everything the product depends on: hosting, third-party APIs, messaging, payments, the EHR connection. You can't patch or monitor what nobody has written down.
- Assign each dependency an owner and a review date, so a change announced by a vendor reaches a person.
- Put scanning and testing on a calendar before anyone asks for it.
- Keep a standing budget for adaptive and preventive work, separate from the feature backlog, so security fixes don't compete with new screens.
- Write down how a fault is reported, ranked and fixed, so an urgent patch follows a known path instead of an improvised one.
None of this needs special tooling. A shared document and a recurring calendar entry cover most of the first three steps, and the discipline is in keeping them current after the first quarter.
The fourth step is the one that gets cut first. Feature requests have a visible sponsor, and a dependency upgrade doesn't, which is how products drift into a state where one forced change takes weeks.
Keeping maintenance close to whoever built the product
Photo by Sergey Meshkov on Pexels
Knowledge of why a system was built a certain way is the most perishable part of it. A team that wrote the integration can usually see what an API change will break; a team handed the codebase later has to rediscover it.
When we built OptimalMD's digital product, we took it from design through development to launch, covering the website, the members portal and the mobile app. You can read how that project came together in the OptimalMD case study.
Whoever does the work, the handover should include documentation, because documentation updates are part of the perfective category, not an afterthought. If you're weighing a build or an ongoing support arrangement, our apps and SaaS service is where that conversation starts.
Where maintenance fits in the wider build
Maintenance is rarely the first line item in a project, yet it outlasts everything else on the plan. Our overview of healthcare software development puts it alongside discovery, design and integration, and the same logic applies to larger systems like hospital management software.
Decide what your yearly upkeep looks like at the same meeting where you approve the build. It is far easier to defend a budget line created on day one than one requested after the first incident.
Frequently asked questions
How do the four types of maintenance get grouped for budgeting?
ISO 14764 groups adaptive and perfective work as enhancements, and corrective and preventive work as corrections. That split is useful for cost accounting, since corrections are about keeping the existing product right and enhancements are about changing it.
What does the proposed HIPAA rule say about an asset inventory?
As reported by Baker Donelson, the proposal calls for a technology asset inventory and a network map showing how electronic patient data moves through a system. Both would be updated at least every 12 months and after changes that may affect that data.
What is software rejuvenation?
It is another name for preventive maintenance, which the IEEE Technology Navigator says overlaps with refactoring. The aim is to repair latent faults before they cause operational failures.
Cover photo by Towfiqu barbhuiya on Pexels
Sources
- Healthcare Data Breach Statistics — HIPAA Journal
- Software maintenance — IEEE Technology Navigator
