## Inspiration
I was reading about Canada's doctor shortage and something just didn't sit right with me. 5.7 million Canadians with no family doctor. And at the same time, 13,000 internationally trained physicians already living here, already qualified, just — stuck. Not because they can't do the job. Because they can't navigate the paperwork.
I looked into it more and found out the CPSO portal basically tells you nothing until after you've applied, paid, and waited weeks. Then you get a letter saying what you got wrong. Some doctors go through that cycle three, four times over years.
That's not a healthcare problem. That's a communication problem. And I thought — this is exactly what LLMs are for. Not to replace the system. Just to translate it.
## What it does
I built a tool where a doctor signs in, uploads their credentials — degree, training certificates, exam results — and gets back a plain English report within minutes. Here's what you've satisfied. Here's what's missing. Here's the one thing you should do right now.
Their case stays alive permanently. They can come back six months later after passing an exam, upload the new certificate, and see their report update in real time. The whole 2-4 year licensing journey tracked in one place.
## How we built it
I built the backend in FastAPI, split into two routers — one for admin stuff like managing the regulatory corpus, one for everything the doctor touches. I put the CPSO requirements into Backboard as a shared RAG corpus at the assistant level, so every doctor automatically runs against the same source of truth. Each doctor's own documents are private to their thread.
I used Auth0 for login — email and password, nothing fancy. The frontend I built in React with Blueprint.js. Single page, clean, feels like a government portal but one that actually works.
## Challenges I ran into
There was a moment where every single analysis call was failing and I genuinely had no idea why. I eventually figured out that LangChain was treating the curly braces in my system prompt as template variables. Something like { "satisfied": [] } was being read as a missing input variable. The error message was cryptic, it took me way too long to find, and the fix was just — move the instructions out of the system prompt and into the message itself.
I also hit several API endpoints that I assumed existed and just didn't. I built polling logic around one, tested it, got 405s back. Had to rethink on the fly.
Hackathon development is humbling.
## Accomplishments I'm proud of
Honestly just that it works. End to end. Real login, real documents, real gap report. That felt good.
But the thing I'm most proud of is a realization I had halfway through building. I kept thinking of this as a doctor tool. Then I stepped back and thought — wait. This is just a pattern. Government document on one side, citizen's situation on the other, LLM in the middle translating. The doctor use case is one instance of something much bigger.
That realization changed how I think about what I built.
## What I learned
Read the API docs before you assume an endpoint exists.
More seriously — I learned that the hard part of this kind of product isn't the technology. The technology mostly works. The hard part is taking a 40-page regulatory document written for lawyers and turning it into something a model can reason about accurately and a person can actually use.
I also learned that architecture decisions made early matter a lot. Putting the regulatory corpus at the assistant level instead of the thread level was a small decision that made everything else cleaner. The whole multi-user system basically fell out of that one choice.
## What's next for IMG Pathway
I want to replace the JSON store with a real database, tighten up the auth, and load the full regulatory corpus — the actual Medicine Act, not just a summary.
But the bigger thing is building the other side. Right now this is just the doctor facing a wall of requirements alone. The natural next step is a reviewer dashboard — a government or clinic-side view of the same thread. Same data, second frontend, zero backend changes needed. That's already built into the architecture. I just need to build the screen.
And then — other provinces. Other use cases. Immigration. Benefits. Permits. Anywhere someone is staring at a government document wondering if they qualify.
That's the thing I want to keep building.
Log in or sign up for Devpost to join the conversation.