In August, the province announced its next call for proposals: 78 new or expanded primary care teams, with the goal of attaching another 600,000 people to primary care on the road to everyone in Ontario having a provider by 2029. The government says 437,000 people have been connected since the plan launched early last year.
Those are big numbers, and they land on the desks of Ontario Health Teams and their Primary Care Networks. OHTs are the ones expected to coordinate proposals, know which practices have capacity, track who has adopted which digital tools, and report progress back to Ontario Health and the Ministry: accurately, repeatedly, and on a timeline they don't control.
Most OHTs are doing that work with a mix of spreadsheets, a shared drive, email threads, and one or two people who know where everything is. That has worked, more or less, through the formation years. It's getting harder to make it work now.
This post is about what a shared data platform for an OHT actually has to do. Not a feature list, but the specific problems it needs to solve, and the ones it shouldn't try to.
The problem isn't a lack of data. It's a lack of one version of it.
An OHT sits in the middle of a network it doesn't own. Every partner (hospital, family health team, community health centre, home care agency, community support organization) has its own system, its own data, and its own reporting obligations. The OHT's job is to see across all of it.
What the OHT itself typically has is a set of lists. Practices and clinics. Providers and their roles. Which practices are members of the OHT and the PCN. Which ones are engaged in which initiative. Who has eConsult, eReferral, Online Appointment Booking. Who has capacity for new patients. Who signed on to the last call for proposals.
Each list is accurate on the day it was made. The trouble starts when the same practice appears on four lists maintained by three people, and a physician retires, or a clinic merges, or a practice switches from a Family Health Organization to a Family Health Team. Now there are four versions of the truth, and the next report to Ontario Health depends on reconciling them by hand.
This is the actual problem a shared platform has to solve. Not "we need a database." We need one record per practice, per provider, per partner, that everyone authorized to see it is looking at, and that changes in one place when the world changes.
Five things the platform has to do
1. Hold relationships, not just records
A practice isn't a row. It belongs to a group, employs providers, holds memberships, participates in initiatives, and adopts tools over time. If the platform stores each of those as separate lists, you're back to reconciling. If it stores them as connected records, so that this provider works at this practice, which is part of this FHO, which is a member of this PCN, then the question "which PCN member practices have a nurse practitioner and no OAB?" is a filter, not a project.
This is the difference between a CRM and what we've called an intelligence engine. CRMs are built to track contacts and activities. OHTs need to track a system.
2. Keep history, not just status
Ontario Health increasingly wants to know not just where things stand but how they got there. How many practices adopted eReferral this year versus last? Did engagement with the chronic disease initiative go up after the outreach push? Did the practices that received IPCT funding actually attach patients at the rate their agreement specified?
A spreadsheet holds a snapshot. Every time someone overwrites a cell, the previous value is gone. A shared platform needs to capture the progression (a practice moved from no digital tools, to eConsult, to eReferral, to OAB, on these dates) so trend questions can be answered without anyone digging through old email attachments.
3. Make routine reporting routine
The reports an OHT produces are mostly the same questions asked at intervals: membership counts, engagement levels, digital adoption, capacity, initiative participation. If each cycle means rebuilding the logic (merging lists, de-duplicating, fixing the practice that got counted twice), that's staff time going to reconstruction rather than analysis.
The platform should hold the reporting logic once, as saved templates against structured data, so the next cycle is a matter of running the report and reviewing it. Consistency between cycles is also a credibility issue: when this quarter's number doesn't match last quarter's, it's usually because the method changed, not the world. Standardized data removes that variable.
4. Respect that partners are partners
An OHT's data platform is not a partner's clinical system, and shouldn't try to be. The OHT doesn't need the hospital's EMR data; it needs to know the hospital is a member, who the contacts are, and which initiatives it's part of. Scope matters here, both for trust and for privacy. Where the platform does hold information about people, such as contacts at practices and providers, role-based access and an audit trail are the baseline, not a premium feature. PHIPA doesn't relax because the data is "just administrative."
There's a practical version of this too: partners will keep using their own tools, and staff will keep using Excel for one-off analysis. That's fine. The platform's job is to be the common source of truth for what has to be shared, trusted, and reported. It doesn't have to replace everything to be useful; it has to be the place everyone agrees is real.
5. Show the geography
OHTs are geographic by design. Where the practices are, where the capacity is, where the unattached population is concentrated. These are map questions. A list of addresses doesn't answer them; a map with practice attributes layered on does. This sounds like a nice-to-have until you're planning outreach or writing a proposal that has to argue for where new team capacity should go.
Three things it shouldn't try to do
Being clear about scope is half of getting a platform like this adopted. In our experience, three things reliably sink OHT data projects.
Trying to integrate every partner system on day one. Integration is expensive, slow, and depends on partners who have their own priorities. Start with the data the OHT owns and maintains itself (the network map, memberships, engagement, adoption) and get that right. Integration can follow where it earns its place.
Building it as a custom project. A bespoke database built by a contractor for one OHT tends to look great at launch and become unmaintainable within two years, when the contractor has moved on and the reporting requirements have changed again. We've written about why configurable usually beats custom for organizations without their own software teams; OHTs are a clear case. The requirements will shift every year. The platform needs to shift with them without a rebuild.
Treating it as an IT project rather than an operations one. The people who will use this are the OHT's program leads, engagement staff, and analysts. If they aren't shaping the data model (what a "practice" is, what "engaged" means, which initiatives to track), the platform will hold the wrong things in the right structure. This is the same lesson we keep learning about change management: the people doing the work have to own the design.
Where AI fits, and where it doesn't yet
Once the data is structured and shared, AI becomes useful in a specific, bounded way: asking questions of it in plain language. "Which practices in the north of our region have capacity and no OAB?" is a question a program lead should be able to ask without writing a query or waiting for an analyst. That's a real time saving, and it's a low-risk use: the AI is reading the OHT's own administrative data and returning a filtered answer, with a person deciding what to do about it.
What AI shouldn't be doing, yet, is making the underlying data. If the records are inconsistent, a language model querying them will confidently return inconsistent answers. The order of operations matters: one version of the truth first, then tools on top of it.
Starting from where you are
If your OHT is running on spreadsheets today, the honest first step isn't buying a platform. It's an inventory: what lists exist, who maintains each one, what each is used for, and where they disagree. That exercise alone usually reveals which two or three data sets actually drive the reporting, and those are what to move first.
From there, the sequence is short. Define what a practice, a provider, and a partner are in your context. Load the current lists, reconcile them once, properly this time, and agree that from that point on, the platform is where changes get made. Set up the three or four reports you produce most often as templates. Then stop maintaining the old spreadsheets.
At Middlesex London OHT, this is roughly the path that's been taken, iteratively, over the past year. It isn't finished, and these things never are, but the OHT now has a single connected view of its primary care landscape that it can report from and build on. That's the foundation the next three years are going to demand.
If your OHT is working through this, we'd like to talk. CarePlan AI is being used as a shared tracking and reporting platform by Ontario Health Teams today. Visit our OHTs page or reach out to compare notes on what's working.
