The short answer
If software your clinicians or staff rely on was built by someone who has left, or by a vendor that no longer supports it, start with an independent code audit, not a rewrite. It shows how the system works, where it is exposed and how hard it is to change. Usually you stabilize, then improve in small tested steps. A rewrite is the costliest, riskiest option: choose it on evidence.
Warning signs you have an inherited-risk application
- Only one person, or nobody, can safely change or deploy it
- No current documentation of what it does, connects to or stores
- Framework, language, database or operating system past end of support
- Nobody knows if it logs who viewed or changed health information
- Passwords or keys sit in configuration files or the code
- Changes made directly on production, with no test environment
- Few or no automated tests, so every change is a gamble
- Clinical or office staff have built workarounds for its gaps
- You could not explain its security to an auditor, privacy officer or insurer
Two or three ticks are common. Five or more: act before it fails, not after.
What a healthcare code audit covers
The whole system, not just the code:
| Area | What we check |
|---|---|
| Architecture | Components, integrations with hospital information, lab or scheduling systems, single points of failure |
| Secure code review | Manual review plus scanning against OWASP ASVS and Top Ten: injection, broken access control, weak sessions, unsafe uploads |
| Sign-in and roles | Directory or single sign-on, roles matching real duties, users seeing records they should not |
| Access logging | Who viewed, changed or exported a record; logs protected and kept |
| Dependencies and SBOM | Every library and version, known vulnerabilities, licence terms affecting use or sharing |
| Secrets | Passwords, keys and certificates in code, scripts or repositories |
Also in the audit
- Data model and quality: structure, duplicate or orphaned records, what a migration would involve.
- Build and deployment: whether it can be built from source, tested and deployed repeatably, and by whom.
- Operations: backups, monitoring, recovery steps and knowledge that lives only in someone's head.
How findings are ranked
Each finding is rated for risk (to patients, privacy, availability or the organization) and effort to fix.
- Critical firstSecurity and privacy issues, whatever the effort.
- Quick winsQuick, low-risk fixes next.
- RoadmapStructural problems, ordered so leadership sees what money buys.
Rather talk it through? If a clinical or hospital application has become a black box, we can audit it and give you ranked findings and clear options. Talk to a Promatics specialist
Your options after the audit
Stabilize
Fix critical findings, remove secrets from code, add monitoring, tested backups and build notes. Almost always first.
Refactor incrementally
Small, tested changes while it stays in service; the strangler fig pattern retires old parts gradually.
Re-platform
Move to a supported framework, database or hosting with limited changes. Suits end-of-life technology.
Rewrite
Replace it when securing or maintaining the code costs too much, or the work has changed.
Cost drivers:
- Code size and condition
- Number of integrations
- Data to migrate, and its quality
- Clinical and administrative user testing
- Time running old and new together
Why big-bang rewrites fail
A one-release rewrite must reproduce years of unwritten rules and edge cases while the old system still needs fixes, so two systems absorb your budget. At cut-over every missed rule surfaces at once, in front of busy clinical staff. Deliver in slices, each tested and cut over separately: risk stays small and progress shows early.
Health applications cannot go dark for a weekend, so plan for:
A parallel run
Old and new process the same work; results are compared.
Rehearsed migration
Counts and spot checks signed off by the people who use the data.
Downtime procedures
Ones staff already know, updated for new steps.
Your change process
Each release reviewed, scheduled and reversible through your change advisory board.
Privacy and accessibility obligations still apply
Anyone who reads the code, copies the database or runs test data handles personal health information for you.
Your agreement should say how; test environments should use masked or synthetic data wherever possible.
A rewrite is the time to fix accessibility, not carry problems forward. General information, not legal advice: your privacy officer and legal advisers should confirm how the rules apply.
When to bring in help
Your team can often stabilize a small application that someone on staff understands and that holds no personal health information, given time and a test environment. Bring in outside help when:
- nobody can safely change it
- it handles personal health information or connects to clinical systems
- its vendor has stopped supporting it
- leadership needs an independent view before funding a rewrite
Our code audit and modernization service delivers a written audit, ranked findings and costed options, then does the work or supports your team. For the years after: application support and maintenance.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- Application Security Verification Standard (ASVS), OWASP Foundation
- OWASP Top Ten, OWASP Foundation
- O. Reg. 329/04 (General) under the Personal Health Information Protection Act, 2004, section 6, Government of Ontario (e-Laws)
- O. Reg. 191/11 (Integrated Accessibility Standards), section 14, Government of Ontario (e-Laws)
- Strangler Fig Application, Martin Fowler
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.