The short answer
A hospital partner must clear more bars than an ordinary development firm: your privacy agreement, real security practices, hosting your policies allow, Ontario's accessibility standard for public-facing applications, integration with your hospital information system and support for as long as clinicians rely on it. You should own the code and documentation and be able to leave cleanly. Vague answers? Keep looking.
Start with what the partner will touch
| Engagement | Check first |
|---|---|
| Build | Privacy agreement, secure development, accessibility, integration approach, ownership |
| Host | Location, support access, tested backups and restores, incident notification |
| Support | Support model, change process, knowledge transfer, end-of-life planning |
| Take over | A code and security audit before committing to a support price |
The privacy terms PHIPA sets
Your privacy office and the agreement determine whether a partner is your agent or a service provider that is not an agent. A non-agent provider whose services let you handle personal health information by electronic means may, under Ontario's PHIPA regulation, use the information only as necessary to provide the services, may not disclose it, and may not let its staff or anyone acting for it access it unless they agree to the same restrictions.
If two or more custodians share personal health information through the application, the partner may be a health information network provider, with added duties:
- notify each custodian of unauthorized access or use at the first reasonable opportunity;
- describe the services and safeguards in plain language, and publish that plus a general description of safeguards;
- keep an electronic record of accesses and transfers;
- give each custodian a written assessment of threats, risks and privacy effects;
- bind third parties to the same conditions and sign a written agreement with each custodian.
General information, not legal advice: your privacy office and legal counsel decide which obligations apply.
Security evidence, not adjectives
Have the partner complete your vendor security questionnaire and give inputs to your threat and risk assessment (TRA) and privacy impact assessment (PIA). Then look for:
Secure code
Peer review, dependency and vulnerability scanning, secrets kept out of source code.
Separate environments
Development, test and production apart; no real patient data in testing unless your privacy office approves.
Controlled access
Multi-factor authentication, least privilege, audit logs of who accessed what and when.
Incident notification
A contract clause with a defined timeline.
Hosting, accessibility and language
- Hosting. Canadian cloud regions support data residency but do not settle everything: ask where support staff are, who can reach production, how backups are tested and what happens in an outage.
- Accessibility. Under Ontario's Integrated Accessibility Standards, every public hospital's internet websites and web content must conform with WCAG 2.0 Level AA (except live captions and pre-recorded audio description), including web-based applications it controls directly or through a contract that allows changes. Patient portals and public forms built for you are in scope.
- French. Serving patients in French? Ask how bilingual interfaces and translation are handled.
Ownership, exit and long-term support
Source code ownership and access belong in the agreement: repositories in your hospital's account, documentation at agreed milestones, escrow if your risk team wants it, transition assistance and data export in usable formats, so changing partners is a project, not a crisis. Hospital applications often run a decade: ask how yours will be kept patched and upgraded, and how many people know it (one developer is a risk). Response targets belong in the support agreement.
What to ask about long-term support
Security patches; framework and dependency upgrades; end-of-life platforms; working with your change advisory board and release windows; regression testing.
Integration and procurement fit
Expect comfort with HL7 v2 through your interface engine, FHIR APIs and the interface team's process (see HL7 v2 and FHIR integration). Ontario hospitals follow the Broader Public Sector Procurement Directive and applicable trade agreements, which set when an open competitive process is required; a good partner responds in your required format and never asks you to work around it.
Rather talk it through? If you are shortlisting partners for a hospital application, send us the scope and your procurement route, and we will answer this checklist in writing. Talk to a Promatics specialist
Objections, answered honestly
Four objections and our answers
| Objection | Our answer |
|---|---|
| "Switching is too risky." | Not with a plan: a code and security audit, overlap with the current provider where you can, knowledge transferred in writing. |
| "We only use the big vendors." | They suit large platforms. Custom and inherited applications need a partner who knows the code, with the same contractual and security discipline. |
| "Our in-house team can do it." | Often, for parts. Keep ownership in-house; add a partner for capacity, after-hours support or a specialist skill. |
| "AI tools can write the code now." | They speed up developers. They do not sign a privacy agreement, answer your questionnaire or take a call when an interface fails. |
Questions to ask any partner
- Will you sign our privacy agreement, as agent or service provider?
- If several custodians connect, how will you meet network provider duties?
- Will you complete our questionnaire and support our TRA and PIA?
- How do you review code, scan dependencies and protect secrets?
- How fast will you report a security incident, and is it contractual?
- Where will the application be hosted, and supported from?
- How do you test public-facing applications against WCAG 2.0 Level AA?
- Who owns the code, and is the repository in our account?
- What documentation do we receive, and when?
- What does transition assistance include if we change providers?
- How will you handle end-of-life and upgrades over five years?
- Can you share relevant references on request?
What working with Promatics looks like
- ScopeApplication, users, integrations, procurement route; written scope, costs in CAD.
- AgreementsYour hospital's privacy and security terms; your questionnaire completed.
- Build or take overNew work in your repositories; inherited applications start with an audit.
- SupportPatching, upgrades and fixes with written response targets.
Managed-service clients get 24/7 monitoring and support.
When to bring in help
A small internal tool without personal health information may not need a partner. Bring one in for patient information, a hospital information system link, public-facing use, years of support or an application whose vendor is gone. For new, existing and inherited applications, see hospital software development, application support and maintenance and a code audit.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- O. Reg. 329/04: General, Personal Health Information Protection Act, 2004, Government of Ontario (e-Laws)
- O. Reg. 51/26: Cyber Security, Enhancing Digital Security and Trust Act, 2024, Government of Ontario (e-Laws)
- O. Reg. 191/11: Integrated Accessibility Standards, Government of Ontario (e-Laws)
- Broader Public Sector Procurement Directive (effective January 1, 2024), Management Board of Cabinet, Government of Ontario
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.