botrage.me
CHAPTER I · PROJECTS 02 · IN DEVELOPMENT

Product build

Tori

Medical appointment scheduling and insurance claims on one platform — in development, also under the Provizor umbrella.

Product
Medical appointment scheduling and insurance claims, on one platform
Umbrella
Provizor IT Services (provizor.co.il)
Domains
tori.md · torimedical.com
Scope
Booking, claims, and the administration around both
Status
In development

What it is

Tori is the second entry under the Provizor umbrella, and the harder one. It takes two jobs that a clinic normally runs on separate rails — getting a patient into an appointment, and getting the insurance claim for that appointment paid — and builds them as one platform instead of two systems that email each other.

It is in development, and this entry will not pretend otherwise: no launch date, no waiting list, no screenshot of a dashboard that does not exist yet. It answers to two names — tori.md and torimedical.com — and it will get an entry with links in it when there is something behind them.

See alsoEntry 01 — the same umbrella, the same pipeline, several years older.

Scheduling is the part a patient sees: a slot, a confirmation, a reminder that arrives at a useful hour. It is also the part that breaks first, because a real clinic day is a chain of small emergencies and every one of them moves somebody else's appointment.

Claims is the half nobody sees and everybody feels. A rejection is rarely a medical disagreement; it is a field in the wrong format, a code that changed in the spring, a document attached to the wrong submission. That work is repetitive, rule-shaped and expensive — which is precisely the shape that automates well, and precisely the shape that punishes guessing.

Booking is the easy half.

What's being built

  1. 01

    Scheduling

    Availability, booking, confirmations and reminders — and the reshuffle for when a clinic's day falls apart at 09:40. Calendars are easy. The exceptions are the product.

  2. 02

    Claims

    Insurance claims from submission through to whatever comes back. Rules that differ per insurer, forms that reject on a technicality, and a queue that remembers what has already been tried so nobody re-files the same mistake twice.

  3. 03

    Everything around it

    The unglamorous half: records, permissions, an audit trail, and admin screens plain enough that the front desk will actually use them on a bad morning. This is usually where scheduling products quietly fail.