A working healthcare AI feature is not a Jupyter notebook with good demo output. It is code that handles real PHI through a BAA-eligible model path, writes back to the EHR via SMART on FHIR, logs every inference call to an append-only audit log, runs eval harness checks against held-out test cases, and surfaces inside the clinician’s actual workflow rather than in a separate tab nobody opens. Discovery Sprint produced the architecture and the plan. MVP Sprint produces the working feature.
Eight weeks. $95,000. Production-grade engineering. End-to-end build of the first use case, ready for clinical validation in a controlled environment. Suitable input for the Pilot-Ready Sprint that hardens it for the first patient encounter.
Our experts are ready to understand your business goals.
“MVP” gets misused. For some vendors it means a prototype — pretty UI, hardcoded outputs, no real backend. For others it means a research project that runs once for a demo. Neither survives the first hospital security review.
The MVP Sprint ships production-grade code. Specifically:
Real PHI through a real BAA-eligible path. The model provider (OpenAI via Azure, Anthropic via Bedrock, Vertex AI, or an on-prem model) has a BAA in force. PHI redaction at the inference boundary is operational. No PHI in prompt logs that are not BAA-covered.
Working EHR integration. SMART on FHIR launch into Hyperspace or PowerChart, FHIR R4 read and write-back to clinical resources, HL7 v2 routing for legacy interfaces — whatever the target EHR requires. The feature works inside the clinician’s actual workflow, not alongside it. See our Epic AI integration page for one common pattern.
Audit log running. Inference-level audit logging at HIPAA §164.312(b) granularity. Append-only. Tamper-evident. Per the healthcare AI audit logging service page.
Eval harness operational. The skeleton built during Discovery is now wired to live test cases. Accuracy benchmarks running. Safety thresholds defined. Drift detection scaffolded for the Pilot-Ready hardening.
Documentation that survives review. PHI flow diagram. Model card with intended use and limitations. Architecture document updated to reflect the actual build. Audit log retention policy. Test report.
What MVP Sprint does not produce: a fully validated clinical product ready for general patient use. That happens in Pilot-Ready Sprint. MVP Sprint produces the feature that is ready to be hardened for clinical use.
The MVP Sprint runs as four two-week internal sprints. Each ends with a working demo and a checkpoint.
Build the foundational layer. Stand up the inference path with PHI redaction. Implement the BAA-covered provider connection. Wire the audit log skeleton. Set up the eval harness scaffolding from Discovery.
End of Sprint 1: a synthetic-data inference can flow end to end through the redaction layer, the model, and the audit log. No EHR integration yet; no clinical UX yet. The plumbing works.
Build the actual AI feature logic — the prompt templates, retrieval patterns, output structuring, response validation. Connect the feature to the target EHR via SMART on FHIR launch or the integration pattern selected in Discovery. Wire up the write-back to the appropriate FHIR resources (DocumentReference, Condition, Observation, etc.).
End of Sprint 2: a real test patient flows through the feature inside the EHR sandbox. Clinical leadership sees the first real demo. This is the milestone payment trigger.
Eval harness goes from scaffolded to running. Real test cases derived from de-identified historical encounters flow through the model. Accuracy metrics start producing useful numbers. Edge cases surface — clinical scenarios the model handles poorly — and prompt templates plus retrieval patterns get tuned.
End of Sprint 3: defensible accuracy numbers across a representative test set. Failure modes documented. UI surfaces refined based on clinical feedback from the Sprint 2 demo.
The feature gets hardened for the controlled-environment validation that follows. Audit logging tightened. Override workflow built (clinicians can disagree with the AI). Model card written. Test report assembled. Documentation package finalized for hospital IT security review.
End of Sprint 4: a working MVP feature ready for clinical validation in a controlled environment. Handoff package complete. Recommendation for whether the feature is ready for Pilot-Ready Sprint hardening.
Every MVP Sprint produces five concrete artifacts:
1. The feature itself. Production-grade code deployed in your sandbox or staging environment. SMART on FHIR launch (if EHR-integrated). Real PHI flow through a BAA-covered path. Audit log running.
2. The eval harness with results. Working harness, populated with real test cases derived from de-identified historical data. Accuracy, safety, and (where applicable) fairness metrics across patient cohorts. Documented failure modes.
3. Model card. Intended use, limitations, training data summary (where relevant), expected performance, known failure modes, recommended human oversight pattern. Suitable for clinical leadership review and regulatory documentation if FDA SaMD applies.
4. Documentation package. PHI flow diagram. Architecture document updated to reflect the as-built feature. Audit log retention policy. Override workflow specification. SOC 2 / HITRUST evidence package starter (when those frameworks are in scope downstream).
5. Handoff recommendation. Written recommendation on whether the feature is ready to harden via Pilot-Ready Sprint, or whether additional MVP work is needed before that step. Includes scope and fixed-price quote for Pilot-Ready if the recommendation is to proceed.
Discovery Sprint output is the input to MVP Sprint. Specifically:
Healthcare AI MVP Sprint scope is deliberately bounded. Things that are not in scope:
Production patient go-live. That requires Pilot-Ready hardening. MVP feature is ready for controlled-environment validation, not unsupervised production use.
Full SOC 2 Type II evidence collection. SOC 2 Type II observation runs 6 months minimum. MVP Sprint produces the engineering artifacts that go into SOC 2 evidence, but the audit itself is downstream. See SOC 2 for healthcare AI.
FDA SaMD submission. When SaMD applies, the regulatory pathway runs in parallel via the FDA SaMD pathway add-on — $60K over 8 weeks, scoped separately from MVP Sprint.
Full BAA Network Setup. When the team is starting from zero on BAA infrastructure, the BAA Network Setup add-on at $80K over 6 weeks runs ahead of or alongside MVP Sprint.
Custom clinical NER training. When standard PHI redaction tools have specialty-specific gaps, custom NER training fits in the Pilot-Ready scope or via dedicated engineering. See PHI redaction services.
The deliberate scope boundary is what makes the $95K fixed price possible. Scope creep is what makes other vendors’ MVP engagements run 2x time and 3x budget.
A common question: do clinicians actually see the MVP feature, or is it dev-team-internal until Pilot-Ready?
The answer in practice: clinicians see the MVP feature twice during the engagement — once at end of Sprint 2 (first real demo on test patients in the EHR sandbox) and once at end of Sprint 4 (final review with accuracy metrics and failure-mode documentation).
This is intentional. Healthcare AI features that are designed entirely without clinical input fail clinical adoption later. Two structured clinical reviews at the right moments produce the feedback that shapes Sprint 3 (edge cases) and the handoff recommendation. More than that breaks the schedule; fewer than that ships a feature clinicians will reject in Pilot-Ready.
When healthcare UX research capacity is added to the engagement, more frequent clinical sessions become possible — useful for higher-risk features where the trust UX is itself a design challenge.
Pricing. $95,000 fixed. Two payment milestones: 50% on contract signature, 50% at end of Sprint 2 (working EHR-integrated demo on test patients).
Timeline. 8 weeks calendar from kick-off. Kick-off typically 1–2 weeks after Discovery Sprint closes when Discovery was with us, 2–4 weeks after contract signature when MVP is the entry engagement.
Contracting. MSA plus SOW. BAA executed before Sprint 1 begins. The MVP Sprint contract references the Discovery output where Discovery happened.
IP and code ownership. Buyer owns the code. The engagement is work-for-hire under standard healthcare technology services terms. Any pre-existing libraries we use are licensed appropriately for the buyer’s use.
Team size. Typically 3–5 engineers including a healthcare AI lead, a clinical data engineer, an EHR integration specialist (if EHR write-back is in scope), and a healthcare-experienced product engineer. For larger or more complex MVP scopes, hire healthcare AI engineers for dedicated capacity at $8K per engineer per month beyond Sprint scope.
Yes, in specific situations. If the buyer has a recent (within 12 months) architecture validation from a prior Discovery, or if the team has shipped a substantially similar production use case before, MVP can be the entry engagement. The MVP timeline still completes in 8 weeks; the kickoff phase adjusts to absorb the discovery work into Sprint 1.
Python is the dominant stack for the AI layer (FastAPI, LangChain-or-equivalent orchestration, model provider SDKs). TypeScript/React for any custom clinician-facing UI when SMART on FHIR. Java or .NET for EHR-integration components when the target EHR requires it. Postgres or Snowflake for clinical data warehouses. Specific stack decisions are made during Discovery and reflected in the MVP plan.
In the EHR sandbox or staging environment, yes. With real or representative test patient data, real PHI flow through BAA-covered providers, real audit logging, real EHR write-back. It is not yet running in production with real patient encounters — that requires Pilot-Ready Sprint hardening for the first clinical pilot.
Typically 1–4 weeks. During the gap the buyer’s leadership reviews the MVP output, decides on Pilot-Ready scope (which may include FDA SaMD work, eval harness expansion, or other add-ons), and the buyer’s compliance team prepares for the controlled clinical pilot. The team is not billing hourly during this gap; the next engagement starts on a defined kick-off date.
The buyer. Work-for-hire under standard terms. Our open-source dependencies are appropriately licensed. We do not retain rights to use the buyer’s specific clinical workflow, prompt templates, or eval harness in other engagements.
Scope creep is one of the most common failure modes for healthcare AI engagements, which is why the MVP Sprint is deliberately bounded. If new scope emerges that did not exist at Discovery, it becomes a separate engagement — either a second MVP Sprint focused on the new scope, dedicated engineers for ongoing capacity, or Pilot-Ready Sprint scope if it logically belongs in hardening.
Clinicians see the MVP twice during the engagement (end of Sprint 2 demo, end of Sprint 4 review). Real clinical use on real patient encounters waits for Pilot-Ready Sprint. The MVP is designed to be evaluable by clinicians but not relied upon for actual patient care decisions until clinical pilot.
Your email address will not be published. Required fields are marked *
Our expert reaches out shortly after receiving your request and analyzing your requirements.
If needed, we sign an NDA to protect your privacy.
We request additional information to better understand and analyze your project.
We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.
If you're satisfied, we finalize the agreement and start your project.