The Record Is Not the Product

The record exists for care

The medical record began as the doctor's private notebook. The casebooks of sixteenth-century physicians were logs of the doctor's practice, kept for reference and teaching. Continuity lived in the physician's memory, if it lived anywhere.

In 1907, Henry Plummer at the Mayo Clinic gathered everything about a patient into a single dossier — one person, one file — and the modern record was born. In the 1960s, Lawrence Weed looked at the chart again and saw that it was still organized wrong: sorted by the source of the paper rather than by the patient's problems. His problem-oriented record turned the chart into an instrument of thought.

Four centuries, one pattern. Every real improvement to the medical record has been the same move: reorganize it around its purpose. And the purpose has never changed. The record exists so the next clinical decision is better than it would have been without it. The record exists for care.

The accident

Paper has to be somewhere.

A paper chart can exist in only one place, so it lived where care happened — the clinic's filing room, the hospital's records department. The record was organized around the building. Your family doctor held one chart about you, the hospital another, the specialist a third. Nobody decided this. It was physics.

Digitization dissolved the constraint. Digital information has no inherent location; it can be everywhere it is needed at once. The move from paper to software was the moment to ask a foundational question: now that the record no longer has to belong to a building, what should it belong to?

We never asked. We recreated the filing cabinet inside proprietary software — faster to search, easier to read, and exactly as walled-in as the paper it replaced. We digitized the medical record, but we never reconsidered who the record should belong to architecturally.

The cost

This is not an inconvenience. It is a patient safety problem.

When a person's history is scattered across organizations and vendors, every clinician is working from a partial story. Medications prescribed elsewhere go unseen. Investigations are repeated because no one can see they were done. The reasoning behind past decisions — why a drug was stopped, why a workup turned left instead of right — evaporates at every boundary. In Canada today, fewer than a third of physicians can share patient information electronically outside their own practice, and fewer than half of Canadians can see their own health information at all.

A century ago the unit record made the patient's story whole within the hospital. We never finished the job. The story is still whole only inside each building — and patients do not live inside buildings.

The mistake

Underneath the fragmentation is an architectural error: we bundled two different things into one product.

The record is the durable account of a person's health — diagnoses, medications, allergies, results, decisions. Its natural lifespan is a human lifetime. It should be as permanent and boring as a land registry.

The application is the software a clinician uses to work with the record — charting, scheduling, prescribing, decision support. Its natural lifespan is a product cycle. It should evolve as fast as software can.

One should outlive everything. The other should be replaceable without ceremony. We welded them together and sold them as a unit — and the consequences follow mechanically. The patient's data becomes the vendor's switching cost. The record's twenty-year continuity hangs on the corporate survival of a software company. And vendors are rewarded for making leaving painful rather than for making the product good.

Regulation can mandate the pipes. It cannot mandate the architecture.

The obvious fix is to legislate openness, and governments are doing it. The United States mandated standardized FHIR interfaces and banned information blocking. Canada is following: the Connected Care for Canadians Act, now moving through Parliament as Bill S-5, would require vendors to exchange data and prohibit them from blocking it. We support these laws.

But watch what actually happened in the United States. Faced with a mandate, incumbents did the rational minimum: they bolted a thin FHIR interface onto the proprietary database they already had. The data still lives in the vendor's private shape; the open standard is a facade in front of it — exposing the regulated minimum, often incomplete, often barely usable, always an afterthought. The regulation moved the pipes. The architecture didn't move at all.

That is the difference between compliance and conviction. A mandate can force a vendor to open a window. It cannot force them to rebuild the house. Interoperability that is retrofitted is a feature, added grudgingly and maintained reluctantly. Interoperability that is native is a philosophy — and you can tell which one a vendor holds by looking at where the data actually lives.

The inversion

Here is the future we are betting on.

Today, "interoperability" means pipes between private filing cabinets — one clinic's system calling another's API, records translated at every hop. The end state worth wanting is an inversion of that picture: the record layer itself becomes shared, publicly governed health infrastructure — provincially anchored, built on the open FHIR standard, with real identity, provenance on every entry, patient-governed permissions, and an audit trail anyone can trust. And the EMRs — all of them, ours included — become applications that plug into it.

This is not a fantasy of a government software megaproject; the graveyard of those is well populated, and we don't propose adding to it. The infrastructure that works is thin: standards, interfaces, identity, governance — federated, not centralized. It works at exactly our scale. Estonia, a country the size of Saskatchewan, has run its national record this way for over fifteen years, and every citizen can see who has looked at their file. Nor is the answer handing one vendor the whole province, which unifies the filing cabinet by giving a single company the cabinet. The record should be unified and public. The applications on top of it should be plural, competing, and replaceable.

What we're building

Canopy is a young company. We are building the next generation of healthcare software from a clean sheet — and the clean sheet is the point, because it let us make one decision incumbents cannot easily make: we never built a proprietary database to defend.

Canopy stores the clinical record natively in the open FHIR standard. There is no private schema underneath with a compliance layer bolted on top — the open standard is how the record lives. Which means the record under Canopy is already separable from Canopy. If a health authority stood up a public record layer tomorrow, Canopy could plug into it, because we already speak its language as our first language, not as a translation.

We are told this is bad strategy — that we are declining to build the moat. That's exactly right, and it is deliberate. A vendor's interest in owning the record is real, which is why you should judge an EMR company by its architecture rather than its promises. Ours is our answer: we hold nothing hostage, because we built nothing to hold it in.

What's left to compete on is everything that actually deserves competition: workflow that respects a clinician's day, an interface that helps you think, automation that erases clerical burden, decision support and AI that catch what tired humans miss, service that answers when the clinic calls. An EMR should keep its customers because it is the best way to practise medicine — never because leaving is impossible.

The story outlives the app

The medical record is not the product. It is the patient's story — and the story should outlive every clinic, every hospital, every vendor, and certainly every application ever used to write it.

We are building Canopy so that when that future arrives, nothing about us has to change. That is what it means to build with conviction instead of compliance: the philosophy is already in the architecture.