Practice operations·
How Ontario Clinic Owners Can Spot Dangerous "Vibe Coded" AI and Choose Systems You Can Trust
Ontario clinic owners face a flood of hastily built AI tools. Learn how to spot vibe coded systems before they create billing errors, PHIPA breaches, or medicolegal.
How Ontario Clinic Owners Can Spot Dangerous "Vibe Coded" AI and Choose Systems You Can Trust
There are a lot of AI tools being pitched to Ontario clinics right now. Scheduling assistants, triage bots, AI-assisted billing, ambient scribing, the demos look clean, the sales decks promise hours back in your week, and the pricing is often surprisingly low.
For related context, see Your Path To Practicing In Ontario Starts Here Immigration Mindset Amp Initial Strategy. Some of these tools are genuinely well-built. Many are not.
The ones that aren't, what developers now call "vibe coded" tools, are built fast, by generalist engineers using AI coding assistants, optimized to look impressive in a thirty-minute demo. They are not optimized for OHIP fee-schedule accuracy, PHIPA data isolation, or the audit trails that protect you when a patient files a complaint or the Ministry comes asking questions.
The risk for Ontario physician-owners is specific: a vibe coded tool doesn't usually fail loudly. It fails quietly, through billing drift, miscoded claims, and data exposure that only surfaces months later. That's the same invisible leakage pattern we see across practices, the 20–40% revenue gap that builds up not from one dramatic mistake but from accumulated small errors that no one catches in time.
This post walks through the questions to ask, the red flags to watch for, and the architecture standards that separate a tool you can trust from one that will eventually cost you.
What Does "Vibe Coded" Actually Mean in a Clinic Context?
Q: I keep hearing "vibe coded", what does that actually mean for a medical practice?
It's a term that came out of the developer community to describe software built primarily through AI-assisted code generation, by someone who doesn't deeply understand the domain they're building for. The developer prompts an AI coding tool, accepts what it produces, and ships it when it "feels right", hence, vibe.
In a general software context, vibe coding is a productivity accelerator. In healthcare, it's a liability.
A vibe coded medical AI tool typically has no domain layer that understands OHIP billing rules, CPSO standards, or Ontario-specific clinical workflows. It may wrap a general-purpose language model in a basic interface, add a few prompts, and call it a billing assistant. The underlying model predicts statistically plausible text, it has no actual understanding of what a correct OHIP claim looks like versus a rejected one.
The tell is usually how the vendor responds when you ask them to explain their system's reasoning. If they can't show you exactly how a billing code was chosen and why, that's vibe coding at work.
The First Ten Minutes: Questions That Expose a Vibe Coded System
Q: What specific questions should I ask a vendor in the first ten minutes to find out if their system is vibe coded? And what does a red-flag answer actually sound like?
Here's what we recommend asking, based on direct experience evaluating these tools:
Ask whether they are fine-tuning an existing model or training one with their own data. If they're fine-tuning, ask where the training data came from and whether it's ethically sourced. Ask whether the work is being done in partnership with data scientists and academic researchers, or whether a full-stack developer built it over a long weekend.
Ask what the technical stack looks like and who their legal team is. Specifically, ask which lawyers put together the IP agreements and the software licence. Healthcare AI involves complex questions around data ownership and liability. A vendor who can't name their legal counsel, or who has a vague answer about "standard terms," is a concern.
Ask for their SOC II report and any other compliance certifications. SOC II is a baseline for any vendor touching healthcare data. If they don't have it, or if they say it's "in progress," that tells you where they are in their maturity curve.
A red-flag answer sounds like enthusiasm without specifics: "We use the latest AI models," "our system is very accurate," or "we're compliant with all regulations." None of those answers tell you anything verifiable.
A trustworthy answer is specific and slightly boring: named model, documented training data provenance, named legal firm, existing compliance certifications you can request copies of.
Whatever they tell you, take it to your own lawyer and do a basic search to verify it. If a patient ever files a complaint, you need to be able to demonstrate that you did your diligence before connecting their data to this system.
For a broader framework on evaluating AI tools for OHIP billing specifically, the post on choosing the right AI for OHIP billing walks through the decision framework in detail.
The Failure Mode That Only Shows Up After Go-Live
Q: What practical problems emerge after a vibe coded AI tool is already running, and where in a billing or triage workflow does the "lost-in-the-middle" hallucination problem actually cause harm?
This is the question that matters most, because demo environments never reproduce real-world complexity.
The core architectural problem with many AI billing tools is that they use basic Retrieval-Augmented Generation (RAG), a system that searches documents and feeds text chunks to the AI. Basic RAG is optimized for text similarity, not clinical structure. When a question involves a patient's full history or a complex billing scenario with multiple codes, the system retrieves disconnected fragments. Critical context gets buried. This is what's called the "lost-in-the-middle" problem: the right information is technically in the system, but the model doesn't weight it correctly and produces a confident, plausible, wrong answer.1
For billing, this means miscoded claims that pass through your EMR without a flag, show up as rejections on remittance advice six weeks later, and require manual re-submission. For triage, the stakes are higher.
On triage specifically: we'd be cautious about any AI triage tool operating without a human in the loop, regardless of how sophisticated the architecture is. In Ontario, symptoms can suggest but never definitively determine an appointment type or clinical pathway. The physician is a contracted associate, their own legal entity, and the clinic manages parts of the practice on their behalf. That professional relationship means the physician carries liability for triage decisions, whether or not AI was involved.
The promise of automation can lead to gradually ceding that judgment to a system that wasn't built for it. That's how a post-go-live failure becomes a medicolegal problem.
The human-in-the-loop requirement isn't optional. It belongs in your contract with any AI vendor.
The Data Isolation Question That Actually Matters
Q: When a vendor says their platform is "secure and encrypted," what follow-up question distinguishes a catastrophically fragile architecture from genuine data isolation, and why does application-level filtering fail in a way PHIPA would treat as a reportable breach?
Think about it the way you'd think about a science lab.
In school, when you're running experiments, you keep everything strictly separate, the samples, the records, the results, to avoid cross-contamination. You don't dump all your experiments into one container and label them differently. The separation is physical, not just organizational.
Most lower-quality SaaS platforms use what's called a Pool Model: all clinic data lives in one shared database, and the system uses application-level filtering to show each clinic only its own records. The data is separated by a label, not by physical architecture.2
The problem is straightforward: a single misconfigured query, a software update that introduces a bug, a developer error during maintenance, any of these can cause one clinic's patient data to appear in another clinic's view. Under PHIPA, that is a reportable breach. You, as the clinic owner, may bear responsibility for that breach even though the failure was entirely the vendor's.
The follow-up question to ask any vendor: "Does each clinic have its own isolated database, or is all tenant data in a shared database separated by filtering?"
A trustworthy answer involves one of three architectures: a Silo Model (completely separate database per clinic), a Bridge/Hybrid Model (distinct schemas with database-level separation), or at minimum, Row-Level Security enforced at the database engine level, meaning data cannot be physically queried without the correct clinic's authentication token.3
If they can't answer this question clearly, or if they say something like "our data is all encrypted so it's fine," that's the Pool Model and it's not acceptable for Ontario healthcare data.
When Connecting Claims Data Creates a Compliance Liability
Q: Is there a point at which connecting your claims data or patient records to an AI tool creates a compliance liability that's difficult to unwind? What should the order of due diligence steps be?
Yes, and this happens more often than people realize, and it doesn't always stop practices from making the mistake.
The most obvious risk is connecting to any AI tool that is not locally hosted or "on premise." Any tool hosted in a third-party cloud means your data is leaving your own environment. That's not automatically disqualifying, but it requires careful vetting of where that data goes, whether it's used for model training, and what jurisdiction it's stored in.
The highest-risk scenario is free or low-cost AI tools that operate by training on user-submitted data. Clinic managers, admins, and even physicians use these tools today, often without realizing what they've agreed to in the terms of service. When someone pastes billing data or patient information into a free AI assistant to "help draft a letter" or "check a code," that data may be training the model. That's a PHIPA breach, regardless of intent.
The order of due diligence matters:
- Legal review first, before any data connection. Have your own lawyer review the vendor's data processing agreement, not just their marketing materials.
- Verify data residency. Where is your data stored? Is it in Canada? Who can access it?
- Confirm the vendor has no right to use your data for model training. This must be explicit in the contract, not implied.
- Run a small pilot with synthetic or de-identified data before any live patient or claims data is connected.
- Document everything. Your due diligence process is part of your defence if a breach complaint is filed.
Once live patient data has been processed by a third-party AI system, unwinding that exposure is extremely difficult. The diligence has to happen before connection, not after.
The Audit Trail Standard That Protects You
Q: If a vendor says they'll "have engineering pull that report," what does that response reveal, and what does a proper audit trail need to show for PHIPA compliance and medicolegal protection?
That response tells you the audit logs are not self-serve. Which means they're probably not immutable either.
A proper healthcare audit trail should be write-once and append-only, meaning it cannot be edited or deleted after the fact, including by the vendor's own team. This is what "immutable" means in practice.4
When a vendor needs to submit an engineering ticket to export your audit log, a few things are likely true: the logs are not in a format you can access directly, the vendor has some level of control over what you see, and the architecture wasn't designed with your compliance obligations in mind, it was designed for operational convenience.
What an audit log needs to show for PHIPA and medicolegal purposes:
- Who accessed the record (user identity)
- Which patient record or resource was accessed
- What action was taken (view, edit, export)
- Timestamp
- IP address or device identifier
You should be able to export this yourself, without vendor involvement, at any time.
There's a cultural signal in this too. When a company's architecture is built around immutable, self-serve audit logs that even the vendor's own team cannot modify, it says something about how that organization thinks about accountability. The team that can't access their own logs, because the system was designed that way intentionally, is operating from a foundation of transparency. That's what you want in a vendor holding your patients' data.
Three Red Flags No Demo Will Show You
Q: Beyond the questions above, are there red flags I can spot without being a technical expert?
Yes. These are observable without understanding the underlying architecture:
1. No explanation of how a specific claim decision was made. If you ask a billing AI why it chose a particular OHIP fee code and it gives you a general answer rather than a traceable chain of reasoning, the system has no audit trail. A trustworthy billing system can show you exactly why it made each decision, linked to the specific rule or data point that drove it.
2. Training data that isn't specific to Ontario. OHIP billing rules are distinct from other provincial schedules and entirely different from US Medicare. A model trained on general healthcare billing data, or US claims data, will hallucinate Ontario-specific codes with confidence. Ask specifically: "What was the training data for your billing recommendations, and how recent is the Ontario fee schedule it references?"
3. "Integration" that is just an API wrapper. Many tools claim to integrate with your EMR but are actually just reading data through an API and passing it to a general-purpose model. There's no governance layer, no Ontario-specific domain logic, no validation step. The word "integration" covers a wide range of actual technical substance, ask what the integration actually does with your data at each step.
These same gaps are what create the billing drift and opacity that show up as invisible revenue leakage over time. The pattern is the same whether the source is manual error or a poorly built AI tool, the losses accumulate quietly until someone looks.
Why Transparency Beats Speed for Ontario Owner-Operators
Q: Isn't a fast automated system better than a slower manual one, even if it's imperfect?
Speed is valuable. But in billing infrastructure, speed without inspectability is how you lose money for months without knowing it.
The standard we apply to our own oversight work at Physicians First is the same one we'd apply to any AI tool: the system has to show its work. Data, then transparency, then accountability, then action. If a tool skips the transparency step, if it produces outputs you can't verify, you're not faster, you're just less aware of your errors.
A slower, inspectable system that logs every decision, ties every OHIP claim to a specific rationale, and flags anomalies for human review will outperform a fast black box over any meaningful time period. The black box will look better in a demo. The inspectable system will look better on your annual revenue reconciliation.
The question isn't whether to automate. Thoughtful automation of the right workflows genuinely does recover time and reduce administrative burden. The question is whether you can see what the automation is doing, and whether a human is in the loop for anything that touches patient safety or billing accuracy.
Our Claims Concierge and Clarity Concierge products are built on that standard. Every decision is traceable. Nothing is a black box.
If you're not sure what your current billing oversight is missing, a free OHIP billing review is a practical starting point, we'll show you exactly where the gaps are and what they're costing.
Frequently Asked Questions
What does "vibe coded" mean in a medical practice context?
Vibe coding refers to software built rapidly through AI-assisted code generation, typically by developers who don't have deep expertise in the domain they're building for. In a clinic context, it means an AI tool that looks polished in a demo but was never built with OHIP billing rules, PHIPA data requirements, or clinical workflow logic in mind. These tools tend to produce confident-sounding outputs with no verifiable reasoning behind them.
How can I tell if an AI billing tool actually understands OHIP rules?
Ask the vendor to show you a specific example of how their system handles a complex billing scenario, a visit with multiple fee codes, a referral premium, or a time-based service. A tool that understands OHIP can walk you through the decision logic step by step, tied to the current Ontario Schedule of Benefits. A tool that doesn't will give you a general answer or redirect to marketing materials. You can also read more about what to look for in our guide to understanding OHIP billing fundamentals.
Can a poorly built AI system cause compliance issues with PHIPA or CPSO?
Yes, in several ways. A Pool Model database architecture can expose patient records across clinics through a single software error. Free AI tools used by staff can transmit patient data to third-party servers for model training. A billing AI with no audit trail makes it impossible to demonstrate compliance if a complaint is filed. Each of these scenarios can result in a reportable PHIPA breach with serious consequences for the physician-owner.
What should I demand from an AI vendor before I connect my claims data?
At minimum: a data processing agreement reviewed by your own lawyer, confirmation of data residency in Canada, explicit contractual language prohibiting use of your data for model training, SOC II certification, documentation of their data isolation architecture (Pool vs. Silo), and self-serve access to immutable audit logs. Do this before any live data is connected, not after.
Is automation worth it if the system can't explain its decisions?
Not in revenue-critical or patient-safety workflows. An AI tool that produces unverifiable outputs introduces the same opacity problem that causes billing drift in manual processes, except now it's happening at scale and faster. The automation benefit only materializes when the system is inspectable enough that errors are caught and corrected before they compound. Speed without transparency is a liability, not an asset.