How We Scope Healthcare Software Projects: From Discovery Call to First Sprint

Healthcare software projects have a higher failure rate than most software categories. The reasons are consistent: clinical requirements that only surface when a clinician actually uses a prototype, HIPAA compliance constraints that were not understood at project start, EMR integration complexity that was estimated based on documentation rather than on what the integration actually requires in production, and stakeholder expectations that were set before the scope was understood. We have worked on enough healthcare projects — and inherited enough failed ones — to have a clear view of what the scoping process needs to cover. Here is what it looks like in practice.

The discovery phase: what we need to know before we write a line of code

Every healthcare project starts with a structured discovery phase. The questions that cannot wait until the engineering phase:

• What PHI does the system handle, and where does it flow? Not a general question — a specific data flow diagram from source to storage to display to archive. Every PHI data point named explicitly.
• What are the integration points, and do they have sandbox environments? An EMR integration that can only be tested against a production environment is a project risk that needs to be quantified and mitigated. HCHB sandbox access alone can add four to six weeks of lead time.
• Who are the actual users, and can we talk to them? Clinicians, coordinators, administrators, and patients use software differently. The person who commissioned the project is rarely the person who will use it daily. We require at least two user interviews with actual end users before finalising requirements for any clinical workflow feature.
• What does "done" look like for the first version? A specific, testable definition of the MVP — not "a care coordination platform" but "coordinators can receive ADT events from HCHB, assign them to care team members, and log a response action against each event, with a full audit trail."

Compliance scoping: the questions most teams skip

HIPAA compliance is not a binary state — a system is not "HIPAA-compliant" or "not HIPAA-compliant" in the abstract. Specific technical and administrative controls must be in place for the specific system, and those controls depend on exactly what PHI the system handles and how it is used. We scope compliance requirements against a standard checklist: BAA status with all infrastructure providers, encryption requirements (at rest and in transit), audit logging scope, access control model, breach notification plan, and risk assessment documentation. Any item that is not clearly covered by the client's existing programme is a project deliverable, not an assumption.

Integration scoping: the source of most healthcare project surprises

Healthcare integrations — EMR, EHR, billing systems, device interfaces — are the most common source of scope and timeline surprises. The scoping questions that save the most time: Does the vendor provide a sandbox environment, and how long does it take to provision one? What is the authentication model (SMART on FHIR, proprietary API keys, VPN-based access)? What is the rate limiting model, and is it documented? What is the support SLA for integration-related questions? Has this integration been done by anyone before, and can we speak to a reference? The last question sounds blunt. It saves months.

The estimate structure we actually use

Healthcare project estimates have three components: the core application (the features the client can describe), the compliance infrastructure (audit logging, access control, encryption configuration, BAA setup — this is consistently underestimated by teams unfamiliar with healthcare), and the integration work (scoped separately per integration, with explicit assumptions about sandbox access and vendor responsiveness). We present estimates as ranges with stated assumptions, not as point estimates with hidden contingency. If the HCHB sandbox takes six weeks to provision and we assumed two, the estimate changes — clients need to understand that assumption before the project starts, not after the timeline slips.

The first sprint: what it must contain

Sprint one is always infrastructure, not features. Authentication system with HIPAA-compliant session management. Audit log table and the middleware that populates it. Encrypted database with the correct KMS configuration. CI/CD pipeline with automated security scanning. A single end-to-end feature that exercises the complete data path from user input through the application layer to the encrypted database, with audit log verification. By the end of sprint one, we know that PHI can be stored, retrieved, and audited correctly. Everything built after that builds on a foundation that is known to be sound.