Discuss your project
Healthcare

Application support and maintenance for healthcare

Healthcare applications are used for years, long after their builders move on. We keep them running, secure and current (monitoring, fixes, patching, upgrades, improvements) under a written agreement that fits your change and downtime procedures.

Discuss your project How the work is delivered

A good fit if

  • An application matters to care or operations, but nobody in-house can support it properly.
  • Its developer or vendor has left, been acquired or stopped responding.
  • Frameworks or servers are near or past end of support; enhancements pile up unbuilt.
  • You need documented multi-year support, or a dependable team behind your digital health product.

Another approach may suit you better if

  • A commercial vendor still supports it well; theirs comes first, and we can coordinate with them.
  • The application retires within months or needs one fix; a handover plan or small project suits.

What is included

  • Service agreement: priorities, response targets, support hours, escalation contacts
  • Monitoring; incidents; problem management for recurring causes; change management
  • Scheduled patching, urgent vulnerability fixes, periodic security reviews
  • End-of-life planning for frameworks, runtimes, databases and servers
  • Tested enhancement releases, with clear notes, from a prioritized backlog
  • Current documentation, runbooks, architecture record, service reports and exit plan

What this service is

Many healthcare applications come from an in-house team, a contractor or a small company rather than a large vendor, yet run something that matters, in hospitals, clinics, labs, care providers and digital health companies alike:

  • Referral processes
  • Departmental databases
  • Lab tracking tools
  • Patient portals
  • Reporting tools
  • Interfaces

Developers move on, frameworks age, every change becomes a risk and nobody knows who to call. We support these applications for the medium and long term, whether we built or inherited them (those from our healthcare software development move straight into support after go-live), with upgrades planned before they become emergencies. When a problem crosses system boundaries, we coordinate your interface team, hosting provider and other vendors.

Support models

ModelWhat it means
Warranty and on-callNew or small applications: warranty after go-live, then fixes and changes on request at agreed rates.
Fully supportedWe run monitoring, incidents, patching, upgrades and releases; your service desk routes calls to us.
Co-supportedYou: first line and small changes. Us: development, patching, upgrades and escalation.
Planned replacementNear end of life: kept stable and secure while a replacement is planned, built or procured.

Healthcare budgets and hospital procurement run on long cycles, so the yearly roadmap review gives leadership time to budget and procure, rather than discovering an unsupported system during an incident.

Privacy, procurement and exit

We work within the restrictions PHIPA places on service providers, complete your vendor security questionnaire and provide inputs to your threat and risk assessment and privacy impact assessment when changes affect personal health information. Hospitals and public agencies can procure through an RFP, RFQ, request for supplier qualification or invitational process; clinics, labs and companies usually start with a written proposal.

Ownership of and access to the source code are set in the agreement, with hand-over at agreed milestones or escrow. Every agreement includes an exit plan from the start: code, documentation, runbooks and credentials handed over as agreed, and help moving support to your team or another provider, so knowledge never sits in one head, ours included.

Delivery

How the work is delivered

Taking over support follows a planned transition before the agreement starts.

  1. Review

    Code, dependencies, hosting, security, documentation and known issues, plus talks with users and current support.

    Output: Readiness report and risk list.

  2. Agree

    Scope, priorities, response targets, hours, reporting and change process, in writing.

    Output: Signed service agreement.

  3. Transition

    Access, monitoring, backups and documentation; shadow the current team; fix the most urgent risks.

    Output: Monitoring, runbooks, stabilization plan.

  4. Support and improve

    Incidents, changes, scheduled patches and upgrades, enhancements, service and risk reports.

    Output: Releases and service reports.

  5. Review the roadmap

    Each year: upgrades, end-of-life dates, enhancements, risks, replacement options, effort and budget.

    Output: Updated multi-year roadmap.

Scope at a glance

Not included unless agreed

  • Licences, hosting and third-party services, unless in a managed agreement
  • Major redesigns or rewrites, scoped as separate projects
  • Out-of-scope systems, and changes only a commercial vendor can make

What we need from you

  • Access to source code, environments, hosting accounts and documentation
  • A named application owner who sets priorities and approves changes
  • Your change, downtime, incident processes; vendor, interface and desk contacts

Before handover

  • Monitoring and alerts tested; runbooks let your service desk route incidents correctly.
  • Rebuildable from version-controlled source; backups proven by restore, recovery documented.
  • Known vulnerabilities listed with dated fixes; an exit plan if you move.

What affects the cost

  • Number, size and age of applications
  • Hours, response targets, after-hours for managed-service clients
  • Condition of code and documentation at takeover
  • Yearly enhancements, releases, and included hosting or monitoring

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

Questions buyers usually ask

Can you support an application you did not build?

Yes, it is common. We review the code, hosting and documentation, or run a full code audit for larger or riskier systems, which also shows whether to stabilize, refactor or replace. The agreement then reflects the real condition, and urgent risks are fixed during transition.

What response times do you offer?

They are set per application in the service agreement, with priorities and support hours, by its importance to care and operations, so we publish no fixed times. Managed-service clients can have 24/7 monitoring and support.

How do you fit our change management process?

We follow your change process, such as a hospital change advisory board, plus maintenance windows and downtime procedures. Releases are tested before submission, with risk, rollback and communication plans; urgent security fixes use your emergency change process.

How do you protect patient information while supporting the application?

We work within the restrictions PHIPA places on service providers: personal health information used only as needed for the service, access limited to staff bound by the same restrictions, and test data outside production where possible. We complete your vendor security questionnaire. Not legal advice.

Is an important healthcare application left without proper support?

Tell us what the application does, how it is supported and what worries you. We will arrange a conversation and suggest a support review.

Discuss application support