Tebra

Role: Senior Product Designer Company: Tebra

The frame

Tebra builds the operating system for independent medical practices — billing, scheduling, analytics, patient communication, and the EHR itself, all in one workspace. I've spent four years here, working at the seam between practice management and clinical care.

The visible work is the screens. But the more important work is the architectural argument underneath them — the thing that determines whether the next decade of features will compound or fight each other.

The thesis: from notes to problems

Most EHRs are encounter-based. Every visit creates a new note, new copy of the patient's history, new fragmented documentation. You end up with a chart that is technically complete and practically illegible — and an AI layer that, however clever, can only summarize narrative text. It cannot reason about a patient because there is no patient model to reason over, only a stack of notes.

The architectural shift I've been arguing for is the Problem-Oriented Medical Record (POMR): the chart is organized around a single, longitudinal list of clinical problems — things the provider is actively diagnosing, treating, or monitoring. Encounters become updates to problems, not filing cabinets. All clinical data — orders, meds, labs, vitals, imaging, documents, notes — anchors to problems.

This is the documentation model used by the most advanced EHRs and the foundation that makes AI-powered care actually work. Without it, AI generates narrative; it cannot support safe clinical action.

Sections were a paper-chart relic

The older mental model — Family History, Social History, Past Medical History, Review of Systems — exists for three non-cognitive reasons: paper chart constraints, billing checklists, and storage convenience. These were buckets for filing, not categories for thinking.

In real clinical reasoning, "father had hypertension" isn't Family History — it's risk context for this patient's problems. "Smokes one pack a day" isn't Social History — it's a causal factor for HTN, COPD, CAD. "Lives alone" isn't a section header — it's a care-planning constraint.

The shift, in one sentence: we're moving from section-based documentation to entity-based documentation, where the note is a narrative that references specific clinical facts rather than dumping entire data categories.

What this means for the UI

The screens become expressions of the architecture, not the architecture itself.

The practice workspace

A medical practice is also a small business. Before any clinical work happens, someone has to know: who's coming today, who's behind on payment, who's waiting on a callback, where the practice stands financially this month. The dashboard is the morning check-in for the whole operation.

The design constraint here was different: every card on this screen is someone's primary job. The practice owner cares most about Practice Analytics and Revenue. The front-desk lead cares about Practice Messages and Today's Appointments. The biller cares about Outstanding Claims. They share the screen and need to spot what's wrong, fast — so priority encoding is consistent across cards, every card is a glance plus a click rather than the whole workflow, and the module set is configurable.

The encounter workspace

This is where the POMR thinking becomes visible. The clinician's working surface holds two things at once: the active encounter note, and a persistent patient summary that travels with them through the visit.

The patient summary isn't a tab to flip to. It's the always-on context that grounds the conversation. Current Situation tells the clinician where the patient is right now. Key Background lists the things that matter for this visit. Active Care Plan shows what's already in motion. Critical safety context — allergies, here flagged Latex and Penicillin — stays visible at the patient header regardless of which panel state is chosen.

The "Start Recording" affordance hints at AI-augmented documentation. The clinician can have the encounter recorded and structured into a note, or write it manually. Both paths sit in the same interface — the AI is an option, not an imposition. And because the underlying record is problem-oriented rather than encounter-dump, what AI generates can actually be wired into clinical reasoning, not just appended to a transcript.

What the architecture pays off

A POMR isn't a UI re-skin. It's a foundation that pays off across the entire product:

• Documentation burden drops. Providers update problems instead of re-typing histories every visit.
• AI becomes useful, not decorative. Structured problems give AI something it can actually summarize, validate, and reason over.
• Feature development accelerates. Care plans, episodes of care, smart summaries, population analytics, risk stratification — all become straightforward when problems are first-class entities.
• Patient safety improves. Trends are visible. Unresolved issues stay flagged. Medications and labs link to the right condition.
• Interoperability gets easier. FHIR's Condition, Procedure, and CarePlan models are problem-shaped. So is regulatory direction.

What this kind of work demands

Most days the most valuable design contribution is not in the visible artifact. It's in the framing — naming the architectural choice clearly enough that the team can debate it, the trade-off case unambiguous enough that leadership can make a real decision, the path from where we are to where we want to be concrete enough that engineering can plan against it.

This work is ongoing.