TeamCare

Overview

GPs coordinate multidisciplinary care through workarounds. TeamCare replaces them.

When a patient has diabetes, kidney disease, and heart failure, their care is split across a GP, an endocrinologist, a podiatrist, a dietitian, an exercise physiologist — each on their own system, in their own clinic, with no shared view of what anyone else is doing. Getting those providers into the same conversation is one of the most effective things a GP can do for that patient. Most don't attempt it, because the coordination overhead makes it easier to skip.

TeamCare removes that overhead. It reads the patient's existing referral history to surface the care team, proposes a meeting time across providers, and embeds a telehealth link — without the GP leaving the patient record. We built against Best Practice (BP Premier) as our reference platform, and designed it to work either as a standalone web app or as a direct PMS integration.

The problem

The coordination is broken — so it mostly doesn't happen

The friction isn't clinical. GPs understand the value of getting a patient's care team in a room together. The problem is that no tool in their workflow makes it easy. Every step — identifying who's involved in the patient's care, finding a shared time, generating a telehealth link, confirming everyone's coming — requires switching systems or chasing people manually.

In practice, most multidisciplinary coordination is either skipped entirely or handled through informal phone calls that leave no record and no follow-through.

Patients with the most complex conditions — the ones who most need structured team communication — are the ones most likely to fall through the gap.

What makes this structurally hard today

• No care team visibility inside the practice management system
• No shared calendar across providers
• Manual telehealth link generation
• Allied health on entirely different platforms (Cliniko, etc.)
• No confirmation loop back to the GP once invites go out

Design process

We started with referrals — and spent half a day building toward the wrong thing.

The team entered the hackathon with a hypothesis around GP referral navigation: helping GPs find the right specialist faster and track where referrals had gone. I facilitated the ideation sessions, and we mapped out the full journey and flow. The concept had legs — until the SME conversations started.

Across multiple conversations throughout the day, the same picture emerged: referral navigation had been an open challenge in the industry for over a decade. HealthLink, MEDrefer, and others were already in the space — established platforms with more resources, still working on it. Platform fragmentation across different GPs and providers was the structural reason no one had cracked it. We'd spent hours building toward a problem that more experienced teams hadn't solved.

That surfaced a genuine decision point for the team: keep pursuing the navigation route against more established players, or pivot to case conference coordination — a feature that had been scoped as a release 2 idea, not yet attempted by anyone, and achievable within the constraints of a single practice and a single platform.

We decided together to pivot. It was a smaller, more honest claim — and it turned out to be a stronger foundation for the demo than the original direction had been.

Key design decisions that came out of the pivot

My contribution

Facilitation, design, and prototype build

My role split three ways across the 48 hours.

Facilitation

I led the structured sessions throughout the day: problem statement definition, ideation, solution mapping, user journey work, and task allocation. In a team with no shared working history, that structure was most of the project management. The harder facilitation work was holding the decision point during the pivot — working through what was actually achievable in scope versus what established platforms had spent years trying to crack, and getting the team to a clearer brief.

UX design

I mapped the core flows with the clinical team, translating domain knowledge into a sequence that made sense to a GP mid-consultation. The widget interaction model — care team surface, slot selection, telehealth embed, confirmation loop — came out of that process.

Prototype build

Self-contained HTML deployed on GitHub Pages, built with Claude as a coding collaborator. For the demo we replicated BP Premier's interface at close fidelity — flat grey chrome, navy patient header, Tahoma fonts — because we knew judges with clinical backgrounds would recognise it on sight. Two complete scenarios: a GP scheduling a conference and a GP joining one on the day.

Outcomes

The GPs confirmed the problem was real — and that no one had solved it

The strongest signal didn't come from the judges. After the event, the clinical team's conversations with colleagues kept producing the same response: GPs could immediately name patients for whom a case conference was overdue, and name the exact friction that had stopped it from happening.

The prototype demo landed as intended. Judges with clinical backgrounds recognised the BP Premier interface immediately, which meant less time explaining context and more time on the concept itself.

The team is keeping momentum going post-hackathon: an interest-capture landing page for GPs and practice managers, an embedded prototype for self-guided exploration, and early conversations about partner API access with Best Practice and Cliniko.

Reflection

Fidelity built trust — and knowing what not to solve for was half the work

The fidelity decision paid off in a specific way. We spent time replicating BP Premier's visual chrome that we could have used elsewhere. But when judges saw the interface, they recognised it immediately — and that recognition transferred credibility to the concept faster than any explanation could have. A wireframe wouldn't have done that.

The more important lesson came from the pivot. Discovering that adjacent problems have been unsolved for a decade isn't a reason to abandon your concept — but it does force a more honest scoping conversation. We weren't going to fix the platform fragmentation that had complicated every referral navigation attempt. We were showing what the coordination workflow could look like if you started from where one practice actually is today. That's a smaller, more truthful claim — and it was a stronger basis for the demo than the broader version had been.