Discuss your project
Healthcare

Code audits, modernization and secure rewrites for healthcare software

Many healthcare organizations depend on applications nobody fully understands. We audit the code, security, build and deployment, tell you plainly what you have, and help you stabilize, modernize step by step or rewrite securely.

Discuss your project How the work is delivered

A good fit if

  • Nobody on staff can confidently explain or change an application holding health information.
  • Its builder is gone, or it runs on unsupported frameworks, languages or operating systems.
  • A renewal, procurement, merger or planned rewrite needs independent evidence before you commit.
  • Security reviews or penetration tests raised findings that need fixing properly.

Another approach may suit you better if

  • You license commercial software without source access; vendor security reviews and contract terms serve better.
  • You need only a penetration test (security assessments), or the application retires within months.

What is included

  • Inventory and architecture: components, data flows, integrations, failure points
  • Secure code review against OWASP Top 10 and ASVS
  • Sign-in, role-based access and audit logging of health information
  • Dependency and licence scan with SBOM; secrets search in code
  • Risk-ranked report in plain language, with recommended fixes
  • Stabilize, refactor, re-platform or rewrite recommendation, and leadership briefing

What this service is

Healthcare runs on more custom software than most people realize, built by former staff, contractors or vendors, or grown over years of quick fixes. It often holds personal health information and carries risk nobody has measured:

  • Referral trackers
  • Clinic scheduling tools
  • Lab tracking databases
  • Patient portals a vendor dropped
  • HIS or EMR interfaces
  • Fast-grown digital health products

An audit answers three questions: what do we have, how risky is it, what should we do? We work from code, history, configuration and the people who use it, even with no documentation, and write for leadership, the application owner and your privacy office. Digital health companies get an independent view before hospitals or clinics rely on their product.

What we look at, in detail
  • Architecture: structure, data flows, languages, frameworks, databases, connected systems, where it runs and single points of failure.
  • Security: OWASP Top 10 and ASVS as reference frameworks, covering input handling, session management, encryption and error handling.
  • Health information: whether every user signs in, access follows roles, and who viewed or changed what, and when, is recorded.
  • Components and secrets: outdated or vulnerable libraries, applicable licences, and passwords, keys or connection strings left in code, scripts or configuration.
  • Engineering basics: tests, version control, build and deployment, environments, backups and documentation.

Stabilize, refactor, re-platform or rewrite

The report ends with a recommendation, not just a list of problems:

OptionWhenWhat we do
StabilizeSound but neglectedFix urgent findings, update dependencies, add monitoring and tests
Refactor incrementallyCore worth keepingReplace weak parts one at a time behind the existing interface (strangler pattern); staff keep working
Re-platformPlatform unsupportedMove off an end-of-life framework, database or operating system
RewriteNot safe or maintainable at reasonable costRebuild securely, keep the business rules, migrate data with checks at each step

Each option shows cost drivers, risks and effect on users, so leadership can compare fairly (refactor or rewrite?).

Secure modernization and working with healthcare

The same team can do the work: code review on every change, automated tests, dependency scanning, no secrets in code, role-based access and audit logging of access to health information. Integrations use your systems' interfaces: HL7 v2 through the hospital's interface engine, FHIR APIs or EMR vendor APIs.

Accessibility. Public-facing web applications are built to WCAG 2.0 Level AA, which Ontario's accessibility standards require of public hospitals and other designated public sector organizations, and of organizations with 50 or more employees in Ontario, for websites and web content, including web-based applications they control.

Ownership of and access to the source code are set in the agreement; we can hand over code and documentation at agreed milestones or place them in escrow, so you are never again left with an application nobody can change. We work within the restrictions PHIPA places on service providers, complete your vendor security questionnaire and provide inputs to your threat and risk assessment (TRA) and privacy impact assessment (PIA). Hospitals and agencies engage us through a quote, an invitational process or a formal solicitation; clinics, labs and companies usually start with a written proposal. General information, not legal advice.

Delivery

How the work is delivered

Audit length depends on the application's size and how quickly access is arranged; the written scope confirms the timeline.

  1. Scope and access

    Agree the questions, access to code and environments, and how health information is protected.

    Output: Scope, access plan, service agreement.

  2. Review

    Architecture, code and controls, dependency and secrets scans, build, deployment and backups.

    Output: Working findings and questions.

  3. Report

    Findings ranked by risk and explained plainly, with fixes and a recommended option.

    Output: Report, SBOM, executive summary.

  4. Decide

    Brief leadership, the application owner and privacy and security staff on options, costs and risks.

    Output: Agreed plan and scoped proposal.

  5. Fix or modernize

    Remediate urgent findings, then modernize in steps or rebuild securely, with tests and documentation.

    Output: Safer application, documents, support plan.

Scope at a glance

Not included unless agreed

  • No certification; we review against recognized frameworks and report findings
  • Legal advice: we flag issues for privacy and legal advisers
  • Remediation or rewrites (quoted after the audit); third-party licences

What we need from you

  • Secure, approved read access to code, history, builds and configuration
  • An application owner, plus documentation, past findings and vendor contracts
  • A signed privacy and security agreement before accessing health information

Before handover

  • Every finding has a risk rating, evidence, plain explanation and recommended fix.
  • Urgent findings reported on confirmation; fixes re-tested before a finding closes.
  • SBOM, inventory, code and reports handed over in maintainable formats, per agreement.

What affects the cost

  • Codebase size, age, languages and frameworks
  • Integrations with HIS, EMR or lab systems
  • Test environment, security depth, documentation, access to people
  • Remediation or rewrite scope chosen afterwards

No package prices: estimates in Canadian dollars from an agreed scope, taxes shown separately.

Questions buyers usually ask

Why not just rewrite the application?

A full rewrite is the costliest, riskiest option and often recreates old problems, because business rules hidden in old code get lost. Many applications are better modernized in stages; the audit gives evidence, and sometimes the answer is a rewrite.

Do you need access to patient data?

Usually not; we prefer code, configuration and test data. If production must be reviewed, we agree how in advance, work within the restrictions PHIPA places on service providers and limit access to what the review needs.

What if the vendor still owns the code?

Your rights depend on the contract. With a source licence or escrow, we work from that; otherwise we review what you can see (configuration, interfaces, behaviour) and help you understand what the contract allows.

Will you fix what you find?

If you want. Remediation is scoped and quoted separately, and findings are written so any competent developer, yours or another vendor's, can act on them. Afterwards, application support keeps it patched, fixed, improved and security-reviewed.

Not sure what is inside a critical application?

Tell us what the application does, who built it and what worries you. We will arrange a conversation and suggest an independent audit scope.

Discuss a code audit