DISCLAIMER: This article reflects my personal experiences as a patient within the Ontario healthcare system and my expertise as a computer scientist and doctoral engineering student. The views expressed are mine alone and do not represent the positions of my employer, London Health Sciences Centre, nor are they related to my professional duties as Chief Information Security Officer.

I recently submitted a brief to the Standing Committee on Social Affairs, Science and Technology regarding Bill S-5, the Connected Care for Canadians Act. The bill mandates health information technology interoperability and prohibits vendor data blocking. These are good objectives that are long overdue, and I support them. But after two decades in Ontario's hospital systems, the interoperability problem I keep coming back to isn't vendors refusing to talk to each other. It's that us as patients can't get our own health data in a format that's actually useful.

Bill S-5 acknowledges this in its preamble. It recognises that the health information of Canadians "is not easily accessible to them." And then the bill does not address this problem at all.

Your Data, Their Terms

Recently I made an attempt to obtain my own medical records dating back to imaging I had done in 2001 after surgery. After about 3 months of requests, follow up, payments to multiple providers I ended up with an incomplete record (e.g. images but no reports) partially in paper format. In one case I had to actually drive to the hospital I wanted to obtain my records from, find a payment office and pay through credit card in person before they would release my paper records to me! I found it impossible to get a complete record in a structured format that would allow me to combine this into a single electronic record I could use for my own care and allow me to share with providers I visit today. You wouldn't be able to import it into another provider's system. You can't feed it into a health applications. I really wasn't able to do anything meaningful with the data I obtained without having to write code to process it myself into a structured, usable format. I'm still hearing accounts heard of patients receiving records on CD-ROMs. In 2026.

In cases where providers have stood up portals to provide access to records while it provides access it's not a complete picture and doesn't allow the patient to pull everything together. Last year I attended an E-Health conference and heard the term "portalitis" referring to a proliferation of disconnected portals, each controlled by a different custodian, none of which talk to each other. One login for the hospital. Another for your family doctor. Another for lab results. Another for imaging. Another for the specialist. Each portal shows you only what that custodian holds, in whatever format they choose to present it, and none of them let you aggregate, or export the data. You end up managing five or six logins to get a fragmented, incomplete picture of your own health. The disconnected portal model doesn't solve patient access, it just digitises the same custodial silos that created the problem in the first place.

This isn't a technology problem. The systems are capable of producing structured, machine-readable data that would support the patients being able to access and manage their own records. The standards to do it properly already exist. HL7 FHIR (Fast Healthcare Interoperability Resources) defines a modern, API-based framework for representing and exchanging health data as discrete, structured resources, e.g. your medications, lab results, allergies, conditions, not as flat documents but structured, usable data. SMART on FHIR builds on top of that with an OAuth 2.0 authorization layer that lets patients grant secure access to third-party applications of their choosing. Think of when you log into an application with your Google or Apple ID and give it permission to access some of your data, that's how SMART on FHIR is intended to work. When you need your complete record, not just a single lab result or medication list, but everything the FHIR Bulk Data Access specification (sometimes called Flat FHIR) provides a standardized export operation that lets an authorized application request all of a patient's data at once, delivered as newline-delimited JSON files that any modern data tool can process. No more hundreds of individual API calls. No more "we'll mail you a CD." One request, one complete export, in structured, computable format. Imagine how powerful this would be when changing primary care providers!

There's also the identity problem. Right now, your digital health identity is comprised of individual logins that custodians provide to you. This could be a hospital MRN in one system, your email address in another, custom patient portal login somewhere else, all with separate passwords to manage and separate multi-factor authentication (MFA) tokens/apps. The patient often doesn't control them, they don't talk to each other, and if you move provinces or switch providers you have to start from scratch. Internationally accepted standards like W3C Decentralized Identifiers (DIDs) offer a different model. A DID is a globally unique, cryptographically secured identifier that you control as opposed to a hospital, a province, or a vendor. You prove who you are through cryptographic keys you hold, not through a login credential that an institution issued you. Paired with W3C Verifiable Credentials, a custodian could issue you a digitally signed, tamper-proof attestation of things like your immunization record, your medication list, or a surgical summary that you carry in a digital wallet and present to any provider, pharmacist, or application that needs it, on your terms. The receiving party can verify the credential is authentic without calling back to the issuing institution. Your identity and your health attestations become portable, patient-controlled, and independent of any single custodian's systems.

Together, these standards can be the foundation for an ecosystem where you, the patient, could authorize an app on your phone to pull your records from every provider you've seen, aggregate them in one place, share them with a new provider or a care management tool, and prove your identity and present verified health credentials. All in structured, computable formats, all under your control. The major clinical information systems deployed in Canadian hospitals already support FHIR. DIDs and Verifiable Credentials are W3C Recommendations and represent the highest maturity level for web standards. The capability is sitting there. The problem right now is that nothing in Canadian law compels a health information custodian to give you your data that way or to issue you portable, verifiable credentials for the health information they hold.

PHIPA section 52(1.1) looks like it grants Ontarians the right to electronic access. And, it does, on paper. But the format has to either meet requirements prescribed by regulation under section 52(1.1)(a) or be specified by Ontario Health under section 52(1.1)(b), with regulation-making authority in section 73(1)(m.0.1). To date, no electronic format has been prescribed that I am aware of. The right exists in statute but it needs to be completed.

At the federal level, PIPEDA Principle 4.9 requires information to be provided "in a form that is generally understandable" (clause 4.9.4), but that means comprehensible (i.e. explaining abbreviations and codes), not electronic. An organization can mail you a paper printout and call it a day.

Bill C-27 would have introduced a data mobility right under the proposed Consumer Privacy Protection Act (section 72), allowing individuals to direct the transfer of their personal information to another organization in a prescribed electronic format. The bill died on the order paper when Parliament dissolved. No comparable data mobility provision exists in any Canadian statute currently in force.

The deeper problem is the custodial model itself. I'm a huge privacy advocate and PHIPA has good intentions but it was written over 20 years ago and needs to be updated for the our modern, digital health systems. Provincial health privacy law designates health information custodians, your doctor, the hospital, the pharmacy, the lab as the legal gatekeepers of your data and tou have to ask them for access. They control the format, timing, and completeness of the response. There's no obligation to give you your data in a format you can actually use. Your health information is generated through your encounters, from your body, about your conditions and the law treats it as institutional property to be guarded, not personal information to be controlled by you. Providers risk fines if they improperly share or disclose your information which leads to a situation where they have to error on the side of caution, restrict access to patient information which leads to the inability to inter operate across health providers or provide the patient their own information.

This gatekeeper dynamic means that even if Bill S-5 succeeds in making clinical systems technically interoperable with one another, patients are still locked out. Data flows between institutions at the discretion of custodians, never at the direction of the patient. Interoperability that doesn't include patient access really isn't interoperability. Making the patient the hub of their own information would have the side benefit of limiting liability for providers and putting decision making control of the medical record in the patient's hands.

The US Shows It Doesn't Have to Be This Way

The 21st Century Cures Act and the ONC Cures Act Final Rule in the United States established a fundamentally different model. Certified health IT must support standardized FHIR R4 APIs for patient access. The USCDI defines minimum structured, machine-readable data elements available through those APIs. Patient-facing API access must be provided at no cost. And the information blocking prohibition covers patient access, not just system-to-system exchange.

Here's what that looks like in practice. An American patient can download a SMART on FHIR-enabled app, authenticate with their health system's patient portal, and the app pulls their records -- medications, lab results, immunizations, clinical notes -- as structured FHIR resources through a secure API. The data isn't a static PDF. It's computable. The app can flag drug interactions, track trends in lab values, or let the patient share a structured medication list with a new provider who can import it directly into their own system. The patient authorizes the access using the same OAuth 2.0 flow you use when you sign into a website with your Google account. It's secure, it's granular, and the patient controls it.

And when a patient needs their complete record -- switching providers, moving to a new state, or just wanting a comprehensive personal health archive -- the FHIR Bulk Data Access standard (Flat FHIR) lets them trigger a single export of everything. The output is newline-delimited JSON: one FHIR resource per line, trivially processable by any application. No proprietary format. No waiting weeks for a records department to burn a disc. A standardized, computable, complete export of your health data, available through the same secure authorization framework.

American patients have a legally enforceable right to structured, machine-readable, API-accessible health data. In Canada we get a PDF if we're lucky.

This isn't about admiring the American healthcare system. It's about recognising that they solved a specific problem -- patient access to computable health data -- that we haven't even attempted to address. The technology exists. The standards are mature and widely implemented. The major EHR vendors operating in Canada -- Epic, Oracle Health, MEDITECH -- all support FHIR APIs in their US deployments. They could do the same here. What's missing is the legal mandate.

Bill S-5: The Right Idea

The core of Bill S-5 is section 5(2)(a), which defines interoperability. Systems must allow users to "easily, completely and securely access and use all electronic health information and exchange all electronic health information with other health information technologies." This is good! That's the right direction but it doesn't go far enough.

But there's a critical qualifier. Interoperability applies only "unless any applicable federal, provincial or territorial law on the protection of personal health information prohibits that access, use and exchange." This carve-out is a fundamental problem. The bill explicitly defers to the very privacy statutes that currently prevent interoperable exchange from happening. We're mandating that vendors build the plumbing while leaving the taps sealed shut by law.

Ontario's Personal Health Information Protection Act, 2004 (PHIPA) illustrates why this matters. PHIPA section 18(3) requires express consent as opposed to implied for disclosures between custodians that aren't for directly providing health care and for any disclosure to a non-custodian. The "circle of care" under section 20(2) sounds broad but is actually quite narrow: it only operates among specific categories of health information custodians, only for providing care to the specific individual, and only when that individual hasn't placed a consent directive on their records.

In practice: an emergency physician who needs a patient's medication history from multiple providers can't access it through interoperable systems if any of the relevant custodians lack clear consent authority for the disclosure. Ontario Health Teams which are the province's own mechanism for care integration are unable to share patient information across member organizations without navigating a consent framework that was designed for a world where one doctor held one chart.

And the liability framework makes it worse. PHIPA provides for damages including mental anguish (s. 65), administrative penalties (s. 61.1), and offences for wilful contraventions (s. 72). A custodian that gets a disclosure wrong faces complaints to the Privacy Commissioner, administrative penalties, damage claims, and potential College proceedings. The rational response? Default to withholding. Don't share unless you're absolutely sure you can. That's the opposite of interoperability.

At the federal level, PIPEDA's consent exceptions in section 7 are narrow -- emergencies threatening life or health (s. 7(3)(e)) and statistical research where consent is impracticable (s. 7(2)(c)). Neither contemplates routine health information exchange across organizations for care delivery, which is exactly what Bill S-5 is trying to enable.

So the bill tells vendors to build interoperable systems, while the privacy laws tell custodians they can't use them, and nobody tells custodians they have to let patients access their own data in a usable format. It's a mandate for capability with no mandate for action.

What Should Be Done

In my brief I make eight recommendations. Here are the ones I think are most critical:

Require patient-facing access standards based on FHIR, SMART on FHIR, and Flat FHIR. Interoperability specifications under section 5(2)(b) should require certified health information technology to expose patient-facing FHIR R4 APIs, support the SMART on FHIR authorization framework so that patients can securely grant access to applications of their choosing, and support the FHIR Bulk Data Access specification (Flat FHIR) so that patients can export their complete records in structured, computable format. Ontario Health should be required to exercise its authority under PHIPA section 73(1)(m.0.1) to prescribe FHIR-based electronic formats as the standard for patient access, not PDF, not paper, but structured, machine-readable data that patients can obtain, share, aggregate across providers, and use in applications that help them manage their own care. The interoperability framework should also incorporate W3C Decentralized Identifiers and Verifiable Credentials to give patients a secure, portable, self-controlled health identity and the ability to carry verified health attestations across providers and jurisdictions. If we're going to mandate interoperability, patients have to be part of it.

Narrow the privacy carve-out. Section 5(2)(a) shouldn't defer entirely to all applicable privacy legislation. Interoperability requirements should apply unless a specific privacy provision has been assessed against the bill's objectives and found to be necessary and proportionate.

Create a trusted exchange framework. Give custodians a regulation-making power to establish frameworks where participating HICs have a deemed permitted-use basis for disclosures, subject to safeguards like purpose limitation, minimum necessary disclosure, security standards, and audit.

Include a liability safe harbour. Custodians who disclose through an interoperable system that meets prescribed standards, in good faith and in accordance with the Act's purposes, should be protected. This directly addresses the rational risk aversion that leads to information withholding.

The Bottom Line

I support Bill S-5. The prohibition on vendor data blocking is welcome and necessary. But vendor behaviour is only one dimension of the interoperability problem.

The more fundamental issue is who health data actually serves. Right now the answer is institutions. Data flows between systems at the discretion of custodians, governed by privacy laws that incentivise withholding, and patients are locked out entirely. You can't get your own records in a format that's useful. You can't direct your data to a new provider electronically. You can't plug your health information into an application that might help you manage your own care. Your data sits in systems you paid for, about conditions you live with, and you have no meaningful control over it.

Interoperability that doesn't include patient access isn't interoperability at all. It's just institutions agreeing to share your information among themselves, on their terms. Bill S-5 addresses the plumbing. It's time to open the taps -- for everyone.

The full brief is available here.