MMedOp Academy medop.io →
MedOp Academy · Executive program

AI in Healthcare
From Strategies to Execution

Eight weeks, eight chapters, one capstone. Learn how to frame, evidence, pitch and execute AI in a real practice, with the MedOp platform as the worked example throughout.

Duration
8 weeks
Format
Online + live virtual
Diagrams & workflows
55
Capstone
Pitch + 90-day plan
Start here

AI in Healthcare: From Strategies to Execution

An eight-week executive program from MedOp for leaders who need to design, evidence, pitch and execute AI in real care settings.

Healthcare consumers expect care that is convenient, personalized and precise, and independent practices are being asked to deliver it with the same staff, the same hours and tighter margins. Artificial intelligence can absorb a large share of the administrative load that stands between a practice and that expectation: intake, scheduling, documentation, eligibility, claims and follow-up. Yet most healthcare organizations still have not moved AI from pilot to production, and the reasons are rarely technical. They are about data quality, trust in the algorithm, staff skills, regulatory exposure and a lack of a clear execution plan.

AI in Healthcare: From Strategies to Execution is MedOp's eight-week program for the people who have to make that move. It is built for practice owners and operators in MedSpa and aesthetics, physical, occupational and speech therapy, and behavioral health, and for the broader community of healthcare leaders, clinicians, consultants and policymakers who guide AI adoption. Throughout, the MedOp platform is the worked example: a system of record for three specialties with an AI workforce built in, which lets us show every concept twice, once in principle and once as it runs inside a practice.

Duration
8 weeks
Chapters
8 + capstone
Diagrams & workflows
55
Live sessions
Weekly office hours + 1
Practice owners and operators

MedSpa, PT/OT/SLP and behavioral-health leaders who need AI to lift revenue and remove administrative hours without adding compliance risk.

Clinicians and clinical leaders

Providers who will live with AI recommendations in the room and want to know when to trust them and when to override.

Healthcare executives and innovators

Leaders designing multi-site or multi-specialty AI initiatives who need a defensible pipeline, evaluation plan and business case.

Consultants, regulators and policymakers

Advisors guiding organizations through adoption, or shaping the rules that govern AI in care delivery.

What you will be able to do
  1. Explain the fundamentals of modern AI methods, including the role of data and computing in building successful applications.
  2. Evaluate existing AI systems in healthcare and name their strengths and weaknesses with evidence.
  3. Identify new opportunities for AI in your practice or organization that address unmet needs.
  4. Assess the ethical implications and potential biases of AI technologies in healthcare settings.
  5. Take an AI-first solution from idea to a pitch and a 90-day execution plan on a real platform.
StrategyframePipelinebuildReal worlddeployEvidencemeasureEthicsprotectBusinessfundPatient dataextendExecution
The course arc. Eight chapters move in the same order a real AI initiative does: from framing a strategy to launching and operating a solution inside a practice.
LearnApplyBuild capstoneRead the chapterRun the practiceactivityKnowledge checkAdd one section toyour capstonePitch + 90-dayexecution planthentheneach weekweek 8
How each week works. Every chapter feeds one section of your capstone, so by Chapter 8 the pitch and execution plan are already written.

Syllabus

The capstone. Across the eight weeks you will ideate, evidence and pitch one AI-first solution for an unmet need in a practice you know. Each chapter ends by asking you to write one more section of it, so the final live session is a presentation of work you have already done, not a scramble. The capstone deliverable is a pitch plus a 90-day execution plan; Chapter 8 supplies the templates.

Program experience

  • Scenario-based assignments drawn from MedSpa, therapy and behavioral-health operations, each mapped to a chapter.
  • Polls and knowledge checks at the end of every chapter, with explanations for every option.
  • Weekly live office hours with a MedOp program facilitator and one live capstone session in week 8.
  • Case studies written as illustrative practice scenarios so the numbers can be worked in the open.
  • Certificate of completion from MedOp Academy on finishing all eight chapters and presenting a capstone.
Chapter summary
In brief

This program treats AI adoption as an execution problem, not a technology problem. Eight chapters follow the order a real initiative runs in: frame a strategy, build and validate a pipeline, carry it into the workflow, measure it honestly, protect the people it touches, fund it, extend it to data from between visits, and launch it on a plan with gates. MedOp is the worked example throughout, so every idea is shown once in principle and once in a running practice.

Key terms
capstonepitch canvas90-day planAI workforcesystem of recordthree specialties
Capstone deliverable this week

Choose the practice you will design for and write one sentence naming an unmet need you have seen there.

Concept chain
FrameBuildDeployMeasureProtectFundExtendLaunch
Concept chain
Takeaways
  • Every chapter writes one section of your capstone; the final session presents work already done.
  • MedOp is the worked example: each concept is shown in principle and inside a running practice.
  • The order of the chapters is the order a real AI initiative runs in.
01
Chapter 1 · Week 1

Foundations of AI for Healthcare Operations

From rules to predictions to language to action: the mental model you need before you can evaluate anything.

AI has come a long way in a short time, and the vocabulary has moved faster than most leaders' mental models. This chapter builds the model you will use for the rest of the course: what the main families of AI actually do, which of them healthcare has already absorbed, and what changed when large language models arrived.

The key distinction for an operator is between systems that predict (a risk score, a no-show probability, a claim-denial likelihood) and systems that generate (a draft note, a patient message, a summary of a long chart). Prediction systems are usually supervised and need historical labels; generative systems are pretrained on vast unlabelled corpora and are adapted with far fewer examples. Both can help a practice, and both fail in characteristic ways.

Objectives
4
Figures
5
Activity
Sort your workflow
Capstone
Task matrix
What you will be able to do
  1. Identify the key moments in AI history and what each made possible in healthcare.
  2. Distinguish supervised from self-supervised learning and say which one a given practice problem needs.
  3. Recognize the strengths and weaknesses of large language models in clinical and administrative settings.
  4. Place generative AI in a practice workflow so that people keep every consequential decision.
1950sSymbolic AIrules and logic1970sExpert systemshand-coded medical rules1990sStatistical MLlearning from data2012Deep learningimaging breakthroughs2017Transformersattention over sequences2020sFoundation modelsself-supervised at scaleNowAgentic AImodels that act in workflows
Seven decades in one line. Each era changed what a healthcare system could delegate to software: first rules, then predictions, then language, and now bounded action inside a workflow.
modelA function learned from data that maps inputs (a visit record) to an output (a probability, a label, a draft).
labelThe answer attached to a training example: did the patient show, was the claim denied, which code applied.
training / inferenceTraining fits the model to historical data; inference applies it to a new case. Cost, speed and risk live mostly in inference.
foundation modelA large model pretrained by self-supervision on broad data, then adapted to many tasks.
hallucinationA fluent, confident output that is not grounded in the input or in fact. The central failure mode of language models.
agentA model wrapped in tools and rules so it can take bounded actions in a workflow, such as booking a slot or filing a claim draft.
Supervised learningLabelled examplesvisit → no-show? yes/notrainModel learns labelpredictRisk score per visitSelf-supervised learningUnlabelled text or signalsnotes, messages, sensor streamspredict the hidden partModel learns structureadapt with few labelsDraft, summarize, classify
Two ways a model learns. Supervised models need someone to have written the answer down for every example; self-supervised models learn the shape of the data first, then need only a small number of labels to specialize.
Lean insummarize a long intakedraft a referral letternormalize free-textVerify firstanswer clinical questionsquote a policy or priceinterpret a labAutomate with reviewcategorize inbound messagessuggest CPT/ICD candidatesflag missing consentsDo not delegatemake a diagnosischange a treatment plansend anything to a patient unseenLanguage taskFactual or clinical taskLowHighWhat is being askedConsequence of error
Where language models belong. Their strength is fluent transformation of language; their weakness is confident error. Position each use by what is asked and by what an error would cost.
Where AI sits in a practice's operationsIntakecollect · generateSchedulingpredict · actEligibilitycheck · actDocumentationdraft · generateCodingsuggest · predictClaimsdraft · actFollow-upmessage · generateAnalyticsexplain · predictActs within limits, auditedGenerates language, human signsPredicts, human decides
The capability map. Eight operational jobs, three kinds of AI. Colour tells you the governance posture before you read the name: teal acts within limits and is audited, blue drafts for a person to sign, amber predicts for a person to decide.
PatientAI workforceFront deskClinicianBooks online orcalls inIntake agent collectshistory + consentEligibility agentchecks coverageReviews exceptionsonlyVisit with pre-draftednote skeletonDocumentation agentcodes + drafts claimSubmits claim,schedules follow-upstructuredflags gapsapprovessignsqueued
A practice day with generative AI in the loop. The agents do the collection, drafting and checking; people keep every decision that touches care or money.
Practice activity

Sort your own workflow

Take one day in your practice and list every task that involves reading or writing language.

  1. Place each task in the four-cell matrix above by what is being asked and by the consequence of error.
  2. For each 'automate with review' task, name the person who reviews and how long they get.
  3. Write down the one task you would refuse to delegate to a model even if it were free. That boundary is the start of your governance policy.
Knowledge check

A practice wants to predict which new patients will not show for their first appointment. Which learning approach is the natural fit, and why?

Historical scheduling data contains the label (showed or did not) for every past visit, which is exactly what a supervised model learns from. A generative model may help with the reminder message, but the prediction itself is a supervised task.
Chapter summary
In brief

AI moved from rules to predictions to language to bounded action, and each era widened what a practice can delegate. Supervised models need labels you already have; self-supervised models need data you already have plus a few labels. Language models are fluent transformers of language and confident makers of error, so every use is positioned by what is asked and what a mistake costs. In an operations platform, agents collect and draft; people keep every decision that touches care or money.

Key terms
supervisedself-supervisedfoundation modelhallucinationinferenceagentconsequence of error
Capstone deliverable this week

Classify the tasks in your chosen practice on the four-cell matrix and name the one you would never delegate.

Concept chain
RulesPredictionLanguageBoundedaction
Concept chain
Takeaways
  • Prediction and generation are different jobs; most practice problems contain one of each.
  • Supervised learning needs labels you already have; self-supervised learning needs data you already have plus a few labels.
  • Language models transform language fluently and err confidently. Position every use by consequence of error.
  • In an operations platform, agents do the collection and drafting; people keep decisions that touch care or money.
Next: Chapter 2 · The AI Development Pipeline
02
Chapter 2 · Week 2

The AI Development Pipeline

A framework for taking an idea through training, validation and deployment without skipping the gates that protect patients and margins.

Creating and implementing an AI healthcare solution is a balance of training, validation and deployment, and the balance is easiest to get wrong at the joints between stages. This chapter walks the pipeline end to end and gives you the artifact that keeps it honest: a framing canvas you complete before any data is pulled.

You will also start your capstone here. By the end of the chapter you should have a one-paragraph description of an AI-first solution for an unmet need you have seen in a practice, expressed as a machine learning problem with a decision and an action attached.

Objectives
7
Figures
7
Activity
Framing canvas
Capstone
Canvas + rung
What you will be able to do
  1. Become fluent in the core AI terminology used by data teams and vendors.
  2. Define a practice problem as a machine learning solution using the framing canvas.
  3. Identify the key pieces of data needed to build a model and what must be held back.
  4. Perform an initial retrospective evaluation and explain what it does and does not prove.
  5. Explain why prospective validation matters and the common ways it is done.
  6. Name the common pitfalls between validation and deployment and the guard for each.
  7. Draft your capstone idea for an AI-first healthcare solution.
ProblemframingdefinesDataassemblyfeedsTrainingyieldsRetrospectiveevaluationpasses?Prospectivevalidationpasses?DeploymentliveMonitoring
The pipeline. Seven stages, two gates. Most failed healthcare AI projects skipped a gate or never defined stage one precisely enough to know what passing meant.
DecisionWhat will someone do differently?UnitOne row = one visit / patient / claimLabelWhat outcome are we predicting?HorizonHow far ahead? by when must we know?FeaturesWhat is knowable at prediction time?ActionWhat happens when the score is high?BaselineWhat do we do today, and how well?Success metricBusiness + clinical, with a numberHarm checkWho is hurt if the model is wrong?
The framing canvas. Fill all nine cells before anyone touches data. The two highlighted cells, the decision and the action, are the ones teams most often leave blank, and a model without an action is a report nobody reads.
Data readiness scorecard for a no-show model (illustrative)not readywork neededreadyVolume (rows with the label)24 mo · 38k visitsLabel availabilityshowed / no-show recordedTimeliness (features at prediction time)insurance verified lateQuality (gaps, duplicates)12% missing phoneAccess (BAA, export, consent)no BAA with SMS vendor
Readiness before modelling. Green, amber and red are the practice's own answer to 'can we build this yet?'. Two red or amber rows here, timeliness and access, would stall the project before training starts; both are fixable in weeks.
Historical records (e.g. 24 months of visits)Train 70%Validation 15%Test 15%Time-based split for operational data:Fit on months 1–18Test on 19–24time →Never let the test months leak into training: that is how a model looks brilliant and then fails in production.
Holding data back. A random split answers 'can the model learn this?'; a time-based split answers the question you actually care about, 'will it work next quarter?'
Retrospective evaluationScore past casesCompare to what happenedAUROC, calibration, PPVAnswers: could it have worked?Prospective validationScore live cases, silentlyshadow modeWait for real outcomesSame metrics + workflow effectAnswers: does it work here, now?
Two kinds of proof. Retrospective results are necessary and cheap. Prospective results are what a clinician, a payer or an investor should ask for before anything changes in the workflow.
Shadowscores silentlyno one sees itAssistshows suggestionhuman decidesApprovedrafts actionhuman clicks approveAutonomousacts within limitshuman audits
The deployment ladder. A model earns each rung with prospective evidence at the rung below. Most healthcare deployments should live on 'assist' or 'approve' for a long time; 'autonomous' is reserved for low-consequence, well-measured tasks.

Pitfalls between validation and deployment

PitfallHow it shows upGuard
Label leakageA feature encodes the answer (e.g. 'claim paid date' predicting denial)Only use features knowable at prediction time
Random split on temporal dataGreat test score, weak in productionSplit by time, test on the most recent period
Class imbalanceAccuracy looks high because the event is rareReport PPV, sensitivity and calibration, not accuracy
Distribution shiftNew payer mix, new location, new seasonProspective validation and drift monitoring (Ch. 3)
Automation biasStaff stop checking because the model is usually rightKeep the review step short but real; sample audits
No action ownerScore is produced, nobody changes behaviourName the owner and the action in the framing canvas
Practice activity

Complete a framing canvas for your capstone

Pick one unmet need in a practice you know: missed first appointments, unsigned notes, denied claims, slow intake, unanswered calls.

  1. Fill all nine cells. If 'action' is blank, the idea is not ready; keep going until someone has to do something differently when the score is high.
  2. List the data you already have that contains the label, and the earliest moment the features are knowable.
  3. Decide which rung of the deployment ladder you would launch on, and what evidence would earn the next rung.
Knowledge check

A denial-prediction model scores 0.94 AUROC on a random split of the last two years of claims. Before you trust it, what is the single most important extra check?

A random split on temporal data and label leakage are the two most common reasons a model looks excellent and then fails. Re-testing on the most recent period with only prediction-time features is the check that exposes both.
Chapter summary
In brief

The pipeline has seven stages and two gates, and most failures happen at the joints. A nine-cell framing canvas, completed before any data is pulled, forces the decision and the action into the open. Hold data back by time, not just at random. Retrospective evaluation proves a model could have worked; prospective validation proves it works here and now. Deploy on a ladder from shadow to assist to approve, and reserve autonomous mode for low-consequence, well-measured tasks.

Key terms
framing canvaslabel leakagetime-based splitAUROCprospective validationshadow modedeployment ladder
Capstone deliverable this week

Complete the framing canvas for your solution and choose the deployment rung you would launch on.

Concept chain
FrameDataTrainEvaluateValidateDeployMonitor
Concept chain
Takeaways
  • Frame before you fetch: nine cells, with decision and action filled in.
  • Hold data back by time, not just at random, and never let test periods leak into training.
  • Retrospective evaluation says 'could have worked'; prospective validation says 'works here, now'.
  • Deploy on a ladder. Shadow first, then assist, then approve; autonomous only for low-consequence, well-measured tasks.
03
Chapter 3 · Week 3

From the Lab to the Front Desk

Label quality, human-centered design, transparency, monitoring and culture: the factors that decide whether a validated model becomes an adopted product.

Leveraging AI in a healthcare setting is hard for reasons that have little to do with model architecture. The label that trained the model was written by a tired person; the score arrives at a desk with 40 seconds to act; the practice changes payer mix in the spring; and, within weeks, staff either ignore the flag or stop checking it. This chapter is about the factors that turn a validated model into an adopted product.

We take them in the order they appear in a real project: label quality, human-centered design, transparency and trust, proactive monitoring, and finally the cultural and economic conditions that decide whether anyone uses the thing.

Objectives
6
Figures
8
Activity
Design the moment
Capstone
The sentence staff see
What you will be able to do
  1. Identify the factors that affect label quality and run an effective labeling workflow.
  2. Follow a human-centered approach to designing the moment where an AI output meets a person.
  3. Distinguish global from local transparency and say what each builds.
  4. Describe the role, timing and importance of proactive monitoring.
  5. Explain how implementation, cultural change and health-economic evidence affect adoption.
  6. Name the gap between lab and real world in five concrete rows.
Raw recordsLabelingQuality controlSample casesstratifiedWrite labelingguide + examplesTwo labelerslabel blindMeasureagreementAdjudicate,revise guideGold set lockedguide v1each casedisagree?guide v2
A labeling workflow that produces trustworthy labels. Agreement between independent labelers is the quality metric; every disagreement improves the guide.
shadow shiftsone decisionpaper firstreal casesiterateObserve the workDefine the momentPrototype inthe workflowTest with staffMeasure effort+ outcomeHuman-centereddesign
Human-centered design loop. The product is not the model; it is the moment the model's output meets a person with 40 seconds to decide. Design that moment first.
Two kinds of transparencyGlobalwhat the model is, in generalLocalwhy this score, for this patientmodel card · training dataintended use · known limitsoverall performancetop contributing factorsconfidence for this casewhat would change the scorebuildsbuildsInstitutional trustTrust in the moment
Transparency at two scales. Leaders adopt on global transparency; clinicians act on local transparency. A deployment needs both or it stalls at one of the two desks.
What builds trust, by stakeholder (relative weight, illustrative)Global transparencyLocal reasonSpeed of useEvidence in own dataOverride controlPractice owner9030409550Front desk3090955070Clinician6095708095Patient5060203080lowhigh
Trust is not one thing. Owners adopt on global transparency and their own numbers; front desks act on speed and a local reason; clinicians need the reason and the override. Design the moment for the person who will use it.
assist / approveloggedweeklydrift?closes loopPredictActObserve outcomeCompare toexpectedAlert or retrainProactivemonitoring
The monitoring loop. Monitoring is not a dashboard someone might open. It is a scheduled comparison of predicted against observed with a named owner and a threshold that triggers action.
Why the lab result does not survive contact with the clinicIn the labIn the practiceDataclean research extractlive records with gaps, typos, duplicatesPopulationone site, one periodnew payers, seasons, locationsWorkflowscore is the outputscore is one input among manyIncentivepublish a metrickeep the schedule full and staff saneFeedbacknone after publicationstaff ignore or over-trust within weeks
The lab-to-real-world gap. Each row is a reason a model that was 'validated' can still fail a practice. Chapters 4 and 5 give the tools that close the first two rows; this chapter closes the last three.
months after go-liveshare of eligible cases where staff act on the flagChampion pilotone desk, one ownerShow the numbershours saved, recovered $Make it defaultin the workflow, not beside it
Adoption is a culture curve. Illustrative shape, not data. The three interventions that bend it are a visible champion, early evidence in the practice's own numbers, and moving the AI into the default path of the work.
Practice activity

Design the moment

Choose one AI suggestion your capstone would produce.

  1. Write the exact sentence the staff member will see, including the local reason and the one action they can take.
  2. Time how long it takes a colleague to read it and decide. If it is longer than 40 seconds, cut it.
  3. Decide what is logged when they accept, edit or ignore, and who looks at those rates every week.
Knowledge check

Three months after go-live, front-desk staff act on only 15% of the no-show flags, down from 60% in month one. Model performance is unchanged. What is the most likely cause and first response?

Unchanged model performance with falling action rates is an adoption signal, not a model signal. The interventions that bend the adoption curve are workflow placement, visible evidence and a champion.
Chapter summary
In brief

A validated model becomes an adopted product only when the label was trustworthy, the moment of use was designed for a person with forty seconds, transparency exists at both global and local scale, monitoring is a scheduled comparison with an owner, and the practice's culture and economics reward using it. The lab-to-practice gap has five rows; this chapter closes the last three and the accept-edit-ignore rate is your live adoption curve.

Key terms
inter-labeler agreementgold sethuman-centered designglobal vs local transparencydriftaccept-edit-ignorechampion
Capstone deliverable this week

Write the exact sentence a staff member will see, the action they can take, and who reviews the rates weekly.

Concept chain
LabelqualityDesign themomentTransparencyMonitoringAdoption
Concept chain
Takeaways
  • Label quality is measured by agreement between independent labelers and improved by adjudication.
  • Design the moment of use before the model; the product is the decision, not the score.
  • Global transparency wins adoption decisions; local transparency wins actions.
  • Monitoring is a scheduled comparison with an owner and a threshold, and accept-edit-ignore rates are your adoption curve.
04
Chapter 4 · Week 4

Transparency, Reproducibility and Generalizability

How to read a risk model's numbers, decide how sure you must be before acting, and know whether a result will travel to your practice.

Risk prediction models estimate the likelihood of a patient outcome, and the number they produce is only useful when everyone around it agrees what it means and how sure it has to be before someone acts. This chapter gives you the evaluation vocabulary, the concept of a certainty threshold tied to the cost of the action, and the two disciplines, reproducibility and generalizability, that decide whether a result travels.

We use a no-show model as the running example because every practice has the data and the decision is low-stakes enough to argue about in the open. The same arithmetic applies to denial risk, sepsis risk and readmission risk; only the costs change.

Objectives
5
Figures
7
Activity
Algorithmic trust
Capstone
Model card fields
What you will be able to do
  1. Identify the common evaluation measures for AI models in healthcare and compute them from a confusion matrix.
  2. Recognize the level of certainty required to take an action and tie the threshold to the cost of that action.
  3. Explain the role transparency plays in selecting and evaluating models, using a model card.
  4. Distinguish methodological from computational reproducibility and their implications for clinical use.
  5. Describe the barriers to generalizability across settings and the approaches that address them.
Actual outcomeNo-showShowedModel flaggedHigh riskLow riskTrue positive80False positive120False negative40True negative760Sensitivity80 / (80+40) = 67%Specificity760 / (760+120) = 86%PPV (precision)80 / (80+120) = 40%Prevalence120 / 1000 = 12%Accuracy840 / 1000 = 84%(misleading when the event is rare)
One thousand illustrative visits. The same model can be described as 84% accurate or as right only 40% of the time when it flags. Both are true; only the second one tells the front desk what to expect.
risk score threshold →sensitivity (catch more)PPV (fewer false alarms)Low thresholdcheap action:extra SMS reminderHigh thresholdcostly action:require deposit
Certainty is a dial, not a fact. Moving the threshold trades sensitivity for precision. The right setting depends on the cost of the action, which is why a cheap reminder and a deposit request should never share a threshold.
Reliability diagram: predicted vs observed no-show rate20%20%40%40%60%60%80%80%perfect calibrationpredicted probability (score bucket)observed rateover-confidentabove 60%
Calibration is the measure operators feel. Illustrative curve. This model is well calibrated below 50% and over-confident above it: when it says 85%, patients no-show 63% of the time. A deposit rule set at 'above 80%' would be acting on a number that is not real.
Reporteda paper or a vendor slide says it worksMethodologically reproducibleanother team can follow the method and get similar resultsComputationally reproduciblethe same code + data gives the same numbers, versionedExternally validateda different site, different period, still holds
The reproducibility ladder. Methodological reproducibility protects against a lucky result; computational reproducibility protects against a silent change. Clinical use should demand at least the third rung.
Site Atrained here · AUROC 0.86Site Bsame specialty, new city · 0.81transferSite Cnew payer mix · 0.74transferSite Ddifferent specialty · 0.62transferGeneralizability falls as thenew setting departs from thetraining setting. Recalibrateor retrain before trusting.
Generalizability, illustrated. Numbers are illustrative. The pattern is real: the further a new site's population, payers or specialty sit from the training data, the more the model needs local recalibration before it is trusted.
What a model card must containIntended use and the decision it supportsTraining data: source, period, sites, sizePopulation: demographics, specialties, payer mixPerformance: sensitivity, specificity, PPV, calibration, by subgroupThreshold in use and the action tied to itKnown limitations and out-of-scope usesMonitoring cadence, drift thresholds and ownerVersion, date and change log
The model card checklist. Eight fields, one page. If a vendor cannot fill it in, they have not done the work in Chapters 2 and 3.
Practice activity

Algorithmic trust: choose a threshold

Using the confusion matrix above, the practice is considering two actions for high-risk visits: an extra SMS reminder (costs almost nothing) and a required deposit (costs goodwill and some bookings).

  1. For each action, decide the minimum PPV you would accept before triggering it, and justify it in one sentence.
  2. Say what level of certainty a clinician would need before acting on a comparable flag in a clinical setting, and why it differs.
  3. Write the two threshold decisions into the 'threshold and action' field of your capstone model card.
Knowledge check

A vendor reports 'our sepsis model is 92% accurate'. Which follow-up question exposes whether that number means anything?

Accuracy is dominated by the common class when the event is rare. Sensitivity, PPV and calibration at the operating threshold, on a named population, are what tell a clinician how often the flag will be right and what acting on it costs.
Chapter summary
In brief

A risk score is only useful when everyone agrees what it means and how sure it must be before action. Report sensitivity, specificity, PPV and calibration at the operating threshold, never bare accuracy. Certainty is a dial tied to the cost of the action. Demand computational reproducibility before clinical use, expect performance to fall at a new site, and make the fall visible on a model card that the practice's own prospective numbers fill in.

Key terms
sensitivityspecificityPPVcalibrationthresholdmodel cardcomputational reproducibilityrecalibration
Capstone deliverable this week

Fill the performance, threshold and limitations fields of your model card, with a PPV floor for each action.

Concept chain
ConfusionmatrixThresholdModel cardReproduceGeneralize
Concept chain
Takeaways
  • Report sensitivity, specificity, PPV and calibration, not accuracy, and always at the threshold in use.
  • Certainty is a dial: cheap actions tolerate low PPV, costly or clinical actions demand high PPV.
  • Demand computational reproducibility (versioned code and data) before clinical use.
  • Expect performance to fall at a new site and plan for local recalibration; a model card makes the fall visible.
Next: Chapter 5 · Bias and Harm in AI
05
Chapter 5 · Week 5

Bias and Harm in AI

Where bias enters, how it compounds, and the ladder of deployment strategies that keep an AI system from harming the people it serves.

The AI development pipeline delivers real benefit and introduces real ethical exposure, and the two arrive together. A no-show model that quietly learns that patients on one insurance plan miss more visits, and then triggers deposit requests for that group, is doing precisely what it was trained to do. This chapter examines each pipeline stage through the lens of ethics and gives you the vocabulary and the ladder of responses you need to run AI in a practice without harming the people it is meant to serve.

The material is not abstract for practice operators. Behavioral-health and therapy practices serve populations with wide differences in access, language and work schedules, and a MedSpa's client data reflects who has historically been marketed to. Every model you deploy will inherit those histories unless you look for them.

Objectives
4
Figures
7
Activity
Bias audit
Capstone
Six doors + subgroups
What you will be able to do
  1. Identify the types and sources of bias in healthcare data and labels and use them to inform labeling strategy.
  2. Contextualize and assess the pros and cons of including demographic attributes in clinical and operational risk scores.
  3. Describe deployment strategies that offset model errors or bias, and order them by intrusiveness.
  4. Recognize a feedback loop and know the two design rules that break it.
Who is inthe dataHow labelswere madeWhich featuresare usedHow the modelis trainedWhere thethreshold sitsHow staffact on itunder-served groupsmissing or sparselabel = past decisions,not true needproxies for race,income, zipoptimizes average,not each groupone cutoff, unequalerror ratesflag confirmsexisting habits
Bias has six doors. Each pipeline stage is an entry point, and the last one, how staff act on the score, is the one most audits forget.
Sources of bias in healthcare data and labelsHistoricalpast care reflects past access, not needMeasurementsome groups measured less, later or differentlyLabellabels encode who was diagnosed, billed or believedRepresentationtraining data thin for some patientsAggregationone model for populations that differDeploymentflag interpreted differently by desk or site
Naming the source tells you the fix. Historical and label bias need different labels or a different target; representation bias needs more data; deployment bias needs workflow design.
actsgenerates labelsfeedsamplifiesModel flagsgroup X moreStaff scrutinizegroup X moreMore denials orno-show recordsfor group XRetraining learnsthe patternFeedbackloop
The feedback loop. A biased flag changes behaviour, behaviour writes the next labels, and the retrained model learns its own past. Break it by auditing error rates by group and by holding out an unflagged sample.
Legitimateattribute changes the truerisk (e.g. age andrecovery time)Proxy for accessattribute stands in forinsurance, distance,work scheduleFairness constraintinclude to equalizeerror rates, not tochange treatmentExcludeno causal story andunequal errors getworse when includedImproves predictionDoes not improve predictionCausal storyNo causal storyEffect on predictionWhy it would matter
Should a demographic attribute go in the model? There is no single answer; there is a disciplined question. Ask what the attribute is doing in the model and whether a proxy for access is being mistaken for a property of the patient.
Harm matrix: consequence of a wrong flag by action and frequencyRareOccasionalFrequentExtra reminder81525Deposit request355575Slot released early456585Discharge from waitlist7085100low harmhigh harm
Rank harm before you rank accuracy. The same false positive is trivial for a reminder and serious for a waitlist discharge. Actions in the dark cells should never share a threshold, or a rung, with actions in the light ones.
Audit bysubgrouperror ratesper groupRe-label orre-targetpredict need,not past useGroup-specificthresholdsequalize PPVor sensitivityHuman reviewfor flagged groupsassist modefor high-harmDemote rung orwithdrawwhen auditfails
Mitigation ladder at deployment. Start with the audit; everything above it is a response to what the audit finds. A model that cannot be audited by subgroup should not be deployed.
Practice activity

Audit your capstone for bias

Take the model your capstone proposes and the data it would train on.

  1. Walk the six doors in the first figure and write one sentence per door on how bias could enter for your specific problem.
  2. Choose one demographic attribute in your data and place it in the four-cell matrix with a justification.
  3. Specify the subgroups you would audit, the tolerance for divergence in error rates, and the first mitigation rung you would apply.
Knowledge check

A therapy practice's no-show model shows equal overall accuracy, but its PPV is 45% for English-preferring patients and 22% for Spanish-preferring patients. Deposits are triggered above a single threshold. What is the most appropriate first response?

Equal overall accuracy can hide very unequal error rates. The lowest mitigation rung that fits a confirmed gap is a group-specific threshold or a human-review step for the high-harm action, while the underlying cause (often reminder language and label bias) is investigated. Removing the attribute does not remove its proxies.
Chapter summary
In brief

Bias enters at six stages of the pipeline, including how staff act on the score, and the fix depends on naming the source. Demographic attributes deserve a disciplined question about what they are doing in the model, not a blanket rule. Feedback loops form when a biased flag writes the next labels; break them with an unflagged holdout and versioned, audited retraining. Mitigation is a ladder that starts with a subgroup audit and ends with withdrawal.

Key terms
historical biaslabel biasrepresentation biasproxyfeedback loopsubgroup auditgroup-specific thresholdholdout
Capstone deliverable this week

Write one sentence per bias door for your solution, choose the subgroups you will audit and the first mitigation rung.

Concept chain
SixdoorsSourcesFeedbackloopAttributequestionMitigationladder
Concept chain
Takeaways
  • Bias enters at six stages; the audit must cover all six, including how staff act on the score.
  • Name the source of bias and the fix follows: labels, data, thresholds or workflow.
  • Demographic attributes need a disciplined question, not a blanket rule.
  • Break feedback loops with an unflagged holdout sample and versioned, audited retraining.
06
Chapter 6 · Week 6

AI Strategy for Practices and Startups

Build, buy, partner or wait; a business case you can defend; the flywheel behind sustainable growth; and the story that gets funded.

AI implementation carries a distinct set of considerations for the people who have to pay for it: a practice owner deciding whether to buy a platform, and a founder deciding whether to build one. The two are the same problem seen from opposite ends of a contract, and this chapter treats them together. You will learn a decision procedure for build, buy, partner or wait; a formula chain that turns operational rates into a defensible business case; the flywheel that separates sustainable growth from a pilot that fades; and the eight beats of an investable story.

This is also where your capstone becomes a pitch. By the end of the chapter you should be able to say, in eight beats, what unmet need you address, what evidence you have, how the economics work and what you are asking for.

Objectives
5
Figures
7
Activity
AI viability case
Capstone
ROI chain + 8 beats
What you will be able to do
  1. Decide between build, buy, partner and wait for a specific AI capability using a repeatable procedure.
  2. Construct an ROI model from measured rates, unit values and adoption, and defend each term.
  3. Explain the growth flywheel and where fragmented tooling breaks it.
  4. Develop an idea for an AI-first healthcare solution into an eight-beat pitch.
  5. Identify sustainable growth strategies for an AI-first healthcare solution or practice.
Is this capability core tohow you win patients?yesnoDo you have data, talentand 12+ months?Does a platform already do itwith your record?yesnoyesnoBuildown the model + dataPartnerco-develop, share IPBuyconfigure, don't codeWait / pilotrun a bounded test
Build, buy, partner or wait. For most practices, AI in operations is not how they win patients; it is how they keep margin. That answer points to buy, and the second question is whether the platform sits on your system of record.
Baselinemeasure current rateChangeexpected rate with AIUnitsvisits, claims, notes / moUnit valueavg visit, avg claim, loaded hourAdoption% of flags acted on (Ch. 3)ValueΔrate × units × value × adoption
The formula chain. Value = change in rate × units × unit value × adoption. The adoption term is the one buyers forget and vendors omit; it is also the one Chapter 3 taught you to measure.
Illustrative monthly value, 6-provider multi-line practiceRecovered no-show visits$4,200 / moDenials prevented$3,100 / moDocumentation hours returned$2,600 / moFront-desk hours returned$1,900 / moFaster consult-to-booking$1,500 / mo
An illustrative ROI model. Figures are a worked example, not a benchmark. The discipline is that every bar is derived from a measured rate (no-shows, denials, minutes per note) multiplied by a unit value the practice already knows.
Per providerpredictable · scales with staffusage / value →monthly feeMetered AI Workforcepay for agents you runusage / value →monthly feeRevenue Recoveryfee tied to recovered dollarsusage / value →monthly fee
Three ways to pay for the same platform. Illustrative shapes. Per-provider is flat and predictable; metered usage rises with the agents a practice actually runs; Revenue Recovery rises only with recovered dollars. Choose the one that matches how your ROI chain behaves, and keep your own merchant account either way.
fundsgeneratesfeedsraisesreturnsMore visits kept+ claims paidMargin to addproviders / linesMore data onthe same recordAgents recalibrate+ improveStaff trust+ act moreGrowthflywheel
The sustainable-growth flywheel. For a practice or an AI-first startup, growth compounds only when the data and the trust stay on one record. Fragmented tools break the wheel at the third node.
Unmet need, in one sentenceWho has it and how manyThe AI-first solution and the decision it changesEvidence so far: retro, prospective, adoptionBusiness model and unit economicsRisks: bias, regulation, generalizability, and your mitigationsTeam and the next 90 daysThe ask
The eight beats of an investable story. Highlighted beats are the ones investors and practice owners remember; the amber beat is the one that builds trust when you say it before they ask.
Practice activity

AI viability: evaluate a case

A start-up offers a stand-alone AI voice receptionist for therapy practices. It answers calls and books appointments into any scheduling system through an integration.

  1. Run it through the decision tree from the practice's side. Which branch does it land on, and what is the second question?
  2. Build its ROI chain for a six-provider practice. Which term is hardest to estimate, and what shadow-mode measurement would settle it?
  3. Identify where the flywheel breaks for a stand-alone tool, and what the founder would have to change to fix it. Apply the same three tests to your own capstone.
Knowledge check

A practice's ROI model for a documentation agent assumes every note is drafted by AI and signed unchanged. Which term in the formula chain is most likely wrong, and how would you fix it?

Assuming 100% adoption is the most common error in AI business cases. Chapter 3's accept-edit-ignore rates give a measured adoption term, and the case should be built on that number, not on the ceiling.
Chapter summary
In brief

Practice owners and founders face the same problem from opposite ends of a contract. Most operational AI is a buy decision, and the deciding question is whether the platform sits on your system of record. A business case is a formula chain: change in rate times units times unit value times adoption, with every term measured. Growth compounds only when data and trust stay on one record, and an investable story has eight beats, with the risks said before they are asked.

Key terms
system of recordunit economicsadoption termflywheelper-provider pricingmetered usageRevenue Recoverythe ask
Capstone deliverable this week

Build the ROI chain for your solution with a measured adoption term and draft the eight beats of your pitch.

Concept chain
Build / buy/ partnerROIchainFlywheelEight-beatpitch
Concept chain
Takeaways
  • Most operational AI is a 'buy' decision; the deciding question is whether the platform sits on your system of record.
  • Value = Δrate × units × unit value × adoption. Measure every term; never assume adoption.
  • Growth compounds only when data and trust stay on one record.
  • An investable story has eight beats; say the risks before you are asked.
07
Chapter 7 · Week 7

AI for Wearable and Patient-Generated Data

Reading the hours between visits: person-generated health data, consent and diversity, sequence models, and detection versus monitoring.

Wearables, phones and home sensors have made it possible to observe patients in the hours between visits, and machine learning is the only practical way to read the resulting streams. The opportunity is largest in exactly the specialties MedOp serves, where outcomes depend on what patients do at home. The risks are also specific: consent that was never really given, devices that work worse for some bodies than others, and models that mistake a change in context for a change in health.

This chapter defines person-generated health data, works through the four considerations that must be settled before it is used, introduces sequence models as the natural tool, and shows where detection, monitoring and engagement applications fit in a practice.

Objectives
4
Figures
7
Activity
Design a detector
Capstone
PGHD + consent spec
What you will be able to do
  1. Recognize the potential scope of person-generated health data (PGHD) and why it matters for care between visits.
  2. Determine the importance of context, scale, consent and diversity considerations for the use of PGHD.
  3. Explain how machine learning approaches wearable data and its connection with sequence-to-sequence models.
  4. Identify applications of wearable data in disease detection, monitoring and engagement and match each to a certainty requirement.
Patient deviceConsent + ingestSequence modelCare teamWearable, phone,home sensorConsent gate:purpose + scopeNormalize to atime seriesDetect patternor changeReview in queuewith contextPatient messageor visitgranted?per patientscore + trendacts
Person-generated health data, end to end. The consent gate sits before ingestion, not after; the model outputs a trend, not a diagnosis; a person decides what reaches the patient.
The scope of person-generated health data (PGHD)Activitysteps, sleep, HRSymptomspain, mood, side effectsAdherenceexercises done, meds takenEnvironmentlocation type, screen timeSocialmessages, check-in cadencePhotoswound, skin, postureThe patientbetween visits
Why PGHD matters. A practice sees a patient for an hour a week at most. Everything in the ring happens in the other 167 hours, and that is where recovery, relapse and adherence are decided.
Contextwhat was the patient doing?same HR means differentthings at rest and at workScaleone patient's baseline vsthousands; benchmarksneed community dataConsentpurpose-bound, revocable,understood; a checkbox isnot consentDiversitydevices, skin tones, ages,languages; a model tuned onone group misfires on othersSignalPeopleInterpretationPermissionWhat the data is aboutWhat can go wrong
Four considerations before using PGHD. Context and scale are interpretation problems; consent and diversity are people problems. All four must be answered in the capstone before a single reading is stored.
Requestedpurpose + scopein plain wordsGrantedper datacategoryActiveingesting; visibleon the recordPausedpatient or clinicianstops the streamRevokedingestion stopsat oncePurgeddata removedper policyre-consent
The consent lifecycle. Consent is a state machine, not a checkbox. Every state is visible on the patient record, and only 'Active' permits ingestion; the dashed return is a fresh consent, never a silent resume.
Daily home-exercise minutes (PT patient)input windowSequencemodelnext-week adherencelikelihood ↓flag: 'drop-off risk'days →
From stream to sequence model. Wearable data is a sequence, and sequence-to-sequence models (the same family behind language models) predict what comes next from what came before. The output is a trend and a likelihood, framed so a therapist can act on it.
Detectionnew or worsening conditionskin change, gait change, mood trajectoryMonitoringknown condition over timepost-procedure recovery, exercise adherence, sleep after a med changeEngagementis the patient still with us?check-in cadence, message response, missed home sessions
Three jobs for wearable ML. Detection carries the highest consequence of error and needs the highest certainty; monitoring and engagement are where a practice should start.
Practice activity

Machine learning for wearables: design a detector

A behavioral-health practice wants to notice early signs of relapse in patients between sessions, using phone-based check-ins and sleep data from patients who opt in.

  1. Define the PGHD categories you would collect and the consent statement a patient would read for each, in plain language.
  2. Specify the input window, the output (trend, likelihood, or both) and who reviews it before anything reaches the patient.
  3. State the diversity risk (devices, languages, age) and how you would audit for it using Chapter 5's ladder. Decide the deployment rung and defend it.
Knowledge check

A PT practice's adherence model flags a drop-off risk for a patient whose recorded exercise minutes fell by half this week. Before outreach, what should the reviewing therapist check first?

Context is the first of the four considerations for PGHD. Wearable streams change for many reasons that have nothing to do with health, which is why the output is a trend for a person to interpret, not an automatic action.
Chapter summary
In brief

Person-generated health data covers the hours between visits where recovery, relapse and adherence are decided. Before storing a single reading, settle context, scale, consent and diversity. Sequence models read streams and predict what comes next; frame their output as a trend for a person to interpret, not a diagnosis. Start with monitoring and engagement, hold detection at assist, and enforce consent at ingestion rather than by policy alone.

Key terms
PGHDconsent gatepurpose-boundsequence-to-sequenceinput windowtrend vs diagnosisdevice diversity
Capstone deliverable this week

Specify the PGHD you would collect, the plain-language consent for each category, and the reviewer before any outreach.

Concept chain
PGHDscopeFourconsiderationsSequencemodelDetect /monitorConsentgate
Concept chain
Takeaways
  • PGHD covers the 167 hours a week the practice cannot see; that is where outcomes are decided.
  • Settle context, scale, consent and diversity before storing a single reading.
  • Sequence models read streams and predict what comes next; frame the output as a trend for a person to act on.
  • Start with monitoring and engagement; hold detection at 'assist'.
08
Chapter 8 · Week 8

Capstone: Pitch and 90-Day Execution Plan

The live session: present an AI-first solution as a nine-cell pitch and a 90-day execution plan with three evidence gates.

A viable pitch is instrumental to securing funding, approval or a pilot for an AI-first healthcare solution, and a viable execution plan is what turns the pitch into something a practice can live with. The final live session brings the cohort together to present both. This chapter gives you the two templates you will present from: a nine-cell pitch canvas whose cells you have been filling since Chapter 2, and a 90-day execution plan with three gates that mirror the deployment ladder.

During the live session, selected cohort members present; everyone evaluates. Use the pitch canvas as your scorecard: an effective pitch fills every cell with a specific, and says the risk cell before the audience asks.

Objectives
4
Figures
5
Activity
Present + evaluate
Capstone
Pitch + 90-day plan
What you will be able to do
  1. Create an effective pitch for an AI-first healthcare solution using the nine-cell canvas.
  2. Recognize the essential elements in a pitch delivered by others and evaluate them against the same criteria.
  3. Lay out a 90-day execution plan with three evidence gates that map to the deployment ladder.
  4. Complete a go-live readiness checklist and know what to do when an item is unchecked.
Unmet needone sentence, one numberWho + how manypractices, patients, visitsSolution + decisionwhat changes at the deskEvidenceretro · prospective · adoptionUnit economicsΔrate × units × value × adoptionRisks + mitigationsbias · regulation · generalizabilityTeamwho owns whatNext 90 daysthe plan on the rightThe askmoney, access, or a pilot
The pitch canvas. Nine cells, one page, presented in eight minutes. Every cell was written in an earlier chapter; the capstone session is where they are read aloud in order.
Pitch scorecard: nine cells, scored 0–1UnmetneedWho +how manySolution +decisionEvidenceUniteconomicsRisks +mitigationsTeam90-dayplanThe askTypical first draftReady to present
Score the pitch before you give it. Illustrative profiles. First drafts are strong on the need and weak on evidence, economics and risks, which are exactly the cells an investor or a practice owner probes. The amber-to-teal gap is the work of Chapters 4 to 6.
W1W2W3W4W5W6W7W8W9W10W11W12W13Baseline measurementData access + consent reviewFraming canvas signed offShadow modeLabeling + gold setRetrospective evaluationModel card v1 + fairness auditProspective results reviewedAssist mode, one deskAdoption + ROI reviewGate 1: framingGate 2: evidenceGate 3: value90-day execution plan (13 weeks)
A 90-day plan with three gates. Nothing moves to 'assist' before Gate 2, and nothing is called a success before Gate 3 shows adoption and value in the practice's own numbers.
Go-live readiness checklistFraming canvas complete, with decision, action and ownerBaseline rates measured and written downData access and consent reviewed; BAAs in place with every vendor touching PHIGold label set with measured agreementRetrospective metrics at the chosen threshold, by subgroupProspective (shadow) results over a defined windowModel card v1 published to the practiceReview queue designed and timed under 40 secondsMonitoring cadence, drift threshold and owner namedRollback: how to demote a rung in one step
Ten checks before go-live. Any unchecked item is a reason to stay at the current rung. The last item is the one most teams have never rehearsed.
Practice activity

Capstone: present and evaluate

Bring your completed pitch canvas and 90-day plan to the live session.

  1. Present in eight minutes, one cell at a time, ending with the ask. Say the risks before the questions start.
  2. Evaluate two other pitches on the canvas: which cell was weakest, and what one measurement would strengthen it?
  3. After the session, revise your plan's Gate 2 evidence based on the questions you could not answer.
Knowledge check

A capstone pitch has strong evidence and a clear ask, but the 90-day plan moves to 'assist' in week 3, before any prospective results. What is the right feedback?

The deployment ladder and the three gates exist so that each promotion rests on prospective evidence from the practice itself. Promoting before Gate 2 is the single most common execution error and undermines the evidence cell of the pitch.
Chapter summary
In brief

The pitch is nine cells you have already written; the live session is where you read them in order and say the risks before anyone asks. Execution is ninety days with three gates, framing, evidence and value, and nothing is promoted before its gate. Ten readiness checks precede go-live, and the rollback is rehearsed. If the idea cannot be configured as an agent with a decision, action, owner, threshold and monitoring cadence, it is not ready to execute anywhere.

Key terms
pitch canvasevidence gateshadow windowreadiness checklistrollbackvalue review
Capstone deliverable this week

Present your nine-cell pitch and 90-day plan; revise Gate 2 evidence after the questions you could not answer.

Concept chain
PitchcanvasGate 1framingGate 2evidenceGate 3valueGo-live
Concept chain
Takeaways
  • The pitch is nine cells you have already written; the session is where you read them in order.
  • Ninety days, three gates: framing, evidence, value. Nothing is promoted before its gate.
  • Ten readiness checks; any unchecked item means stay at the current rung.
  • If the idea cannot be configured as an agent with a decision, action, owner, threshold and monitoring cadence, it is not ready to execute.
Featured case scenarios

Four practices, worked in the open

The course uses illustrative practice scenarios rather than named organizations so that every number can be shown and every decision argued.

Scenario · PT/OT/SLP

Coastal Therapy Group: first-visit no-shows

A four-location outpatient therapy group frames a no-show model, discovers its labels encode a reminder-language problem, sets group-specific thresholds and moves from shadow to assist in eleven weeks. Used in Chapters 2, 4 and 5.

Scenario · MedSpa

Aesthetic consult-to-booking

A two-provider MedSpa uses an intake and follow-up agent to lift consult-to-booking conversion, and learns that the adoption term, not the model, decides the ROI. Used in Chapters 3 and 6.

Scenario · Behavioral health

Between-session check-ins

A behavioral-health practice designs a consent-gated check-in stream and a sequence model that produces a trend, not a diagnosis, and holds detection at 'assist'. Used in Chapter 7.

Scenario · Multi-line practice

One record, three service lines

An integrated practice adds a second specialty and finds that generalizability, model cards and one patient record decide whether its agents survive the move. Used in Chapters 4 and 8.