CliniCore
Outpatient Clinic Operations Platform
- Check-in09:12
- Consultation09:20
- Documentation09:38
- Prescription09:44
- Billing reviewOpen
Procedure recorded with location. Two open items for billing.
A clinic operating layer connecting appointments, clinical documentation, prescriptions, imaging, and billing around a single patient visit.
- Product Manager / Product Owner
- Product Definition · Clinical Workflows · Structured Data · Billing Logic
- Visit-to-Billing Workflow
- Structured Dental Documentation
The visit existed everywhere and nowhere.
Clinicians documented in whatever way was fastest, usually free text. Billing needed structure. Those two needs pulled in opposite directions, and the front desk absorbed the difference.
Anything missing at the end of a visit — a procedure not recorded, a tooth not specified, a prescription written outside the system — turned into a billing correction later.
In an outpatient clinic, the visit is the unit that everything attaches to: the appointment, what the clinician recorded, what was prescribed, what was imaged, and what gets billed.
In practice those were separate records that happened to share a patient name, and the reconciliation happened in someone's head at the end of the day.
Watch a clinic day, not a demo.
Time inside a consultation is the real constraint. I watched how documentation actually happened while a patient was in the chair, and where clinicians chose speed over structure.
Every design idea that added a step to that moment was, correctly, going to be ignored.
Structure at the point of care, not after it.
We defined a visit record where clinical actions were captured as structured entries that billing could read directly, with free text alongside rather than instead.
For dental work, that meant documentation anchored to tooth-level mapping, so location and procedure were recorded together.
Billing derived from the clinical record.
Billing logic consumed the visit record rather than asking staff to re-enter it. Where a mapping was ambiguous, the product surfaced it as an open item on the visit instead of silently guessing.
The billing view became a checklist against the visit, which is how the front desk already thought about it.
Decisions I’d defend.
Block the visit until billing data is complete
Finish the visit, flag what billing still needs.
- Clinical time is the scarce resource
- Product stops being something to work around
- Open items surface instead of guesses
Structure every field
Structure only what a downstream workflow needs.
- Structure has a cost in the room
- Free text stays alongside, not instead
- Billing reads the record directly
Clinicians finish the visit; the system flags what billing still needs. Getting that order wrong would have made the product something to work around.
We only enforced structure on the fields that downstream workflows genuinely needed. Structure has a cost in the room, and it should be paid for by something real.
Documentation, prescriptions, imaging, and billing state all render on the same visit timeline, so no one has to assemble the story from four screens.
Shipping reality.
Clinical products punish carelessness. We kept scope tight, wrote acceptance criteria around edge cases rather than happy paths, and spent real review time on how the product behaves when data is incomplete.
Some legacy data would never be clean. We designed around coexistence instead of pretending a migration would fix it.
What it taught me.
In clinical software, the person with the least available attention should have the simplest surface.
Structured data is a product decision with a human cost. It's worth it when something downstream depends on it, and it's friction when it doesn't.