Your Protocol Is Software Waiting to Be Compiled

Your protocol is already software. Nobody has compiled it yet, so it only runs on one machine: you. When that machine gets tired, retires, or takes a vacation, the program stops.

I spent twenty years writing software before I spent fifteen years as a functional medicine patient. I've sat across the desk from doctors who could diagnose in four minutes what took three specialists four years to miss. I've also watched that same diagnostic skill disappear the moment the doctor left the room, because it lived nowhere except her head.

That's the part that breaks my engineer brain. You built an economic engine and gave it a single point of failure: you.

What I actually see when I watch a doctor work

I don't see intuition. I see a decision tree.

A patient walks in with fatigue, brain fog, and joint pain. You ask about sleep. Depending on the answer, you branch one direction. You ask about gut symptoms. Depending on the answer, you branch again. Somewhere around question six or seven, you've narrowed a thousand possible causes down to three, and you already know which labs to run to confirm.

That's not magic. That's a decision tree with weighted branches, and I've built a hundred of these for companies that had nothing at stake but conversion rates. You're running one with someone's health on the line, doing it from memory, and doing it again, alone, forty times a week.

Structured things can be encoded. Your intake sequence is structured. Your protocol logic is structured. Your follow-up cadence is structured. If it has a repeatable order, a set of rules, and a decision point, it's not "clinical art." It's a spec you haven't written down yet.

The asset you're renting out

Here's the part that should make you angry, not proud.

Every day you don't encode this, you're renting out the only copy of a valuable asset to whoever happens to book an appointment. One patient at a time. One hour at a time. The moment you stop seeing patients, the asset stops producing. That's not a business. That's a very well-paid job with your name on the building.

An asset earns without you standing next to it. A dataset, once structured, answers new queries forever without needing to be re-derived. Your protocol has both of these properties buried inside it right now. You just haven't pulled them out of your head and put them somewhere that runs on its own. See Asset Leverage for how this plays out beyond the clinical side of the practice.

Once you encode it, it stops being "how Dr. Smith practices" and starts being a system Dr. Smith built. Those are different businesses. One sells for a multiple of collections. The other sells for a multiple of nothing, because it walks out the door with you.

The punchline

Your practice is a dataset that happens to see patients.

Every intake form, every lab panel, every follow-up call is a row you're generating and then throwing away. You could be building the most valuable proprietary dataset in your specific niche of medicine, and instead most of it lives in paper charts and your own recall.

The encode-your-protocol inventory

This is the method. I'm not holding any of it back. Grab a notebook, or open a doc, and go through your week looking for these three patterns.

Step 1: Find the decision points. For one week, every time you make a clinical or operational judgment call, write down:

• What information did I need to make this call?
• In what order did I ask for it?
• What made me choose path A over path B?

You are looking for anything you do the same way more than twice. Twice is a coincidence. Three times is a pattern. A pattern is a rule waiting to be written down.

Step 2: Sort each pattern into one of three buckets. Not everything encodes the same way. Match the pattern to the right output.

1. Becomes an assessment if it's a scoring or triage decision: something that takes a set of inputs and produces a category or a risk level. Symptom questionnaires, root-cause screeners, and readiness scores all live here.
2. Becomes a program if it's a sequence: a set of steps a patient moves through in order, where step two depends on how step one went. Protocol phases, supplement ramps, and phased elimination diets live here.
3. Becomes an automation if it's a cadence: something that should happen at a fixed interval regardless of what else is going on. Follow-up check-ins, lab re-tests, and adherence nudges live here.

Step 3: Ship the simplest version first. Do not try to encode the whole protocol at once. Pick the single pattern that repeats the most, and build only that one.

• If it's an assessment, that's a scored questionnaire, a form with logic branches and a result page. No AI required. Just structure.
• If it's a program, that's a sequenced set of instructions a patient can follow without you present, delivered on a schedule.
• If it's an automation, that's a trigger and an action. Lab due in 90 days, send this message. Adherence drops, send that one.

I built this exact way for Dr. Piper Gibson: a genetics-based program tool that takes her clinical logic for interpreting a patient's genetic panel and turns it into calculators and a structured program path, so the reasoning she'd normally do live in a consult now runs the same way every time, for every patient, without her re-deriving it from scratch. Same method with Dr. Diane Mueller, Dr. Alison Egeland, and Dan Lievens: find the repeatable logic, build the smallest tool that runs it, ship it, then expand.

Worked model, stated assumptions: say your intake screener replaces 20 minutes of a 45-minute new patient visit, and you see 8 new patients a week. That's roughly 160 minutes a week returned, about 2.5 hours, which is room for one more full patient slot without adding an hour to your schedule. The math depends entirely on your visit length and volume. Run your own numbers before you believe mine.

Where authority fits into this

An encoded protocol does something else too: it becomes provable. When your logic is written down as a set of rules instead of a feeling, you can explain it, teach it, and defend it. That's a different kind of credibility than "trust me, I've done this a long time." It's demonstrable expertise, which is the kind that scales past your own reputation. More on that distinction in Authority Leverage.

The first thing to encode

Start with your intake. It's the pattern every patient touches, it's the one you've refined the most without realizing it, and it's the easiest to test because you get new data every single week.

Write down your first ten questions and the branches under each answer. That's step one of the inventory, done. You don't need a developer. You don't need a platform. You need one week of paying attention to what you already do, and the willingness to write it down instead of trusting it to memory one more time.

Do this yourself. It costs nothing but attention, and the notebook you fill out this week is worth more to your practice than another year of doing the same decision tree from scratch, patient after patient, with nothing left over when you're done.

If you get partway through the inventory and want a second set of eyes on which patterns to build first, that's what I do. Work with me.