Product discovery for healthcare software
Healthcare product discovery is a short, fixed-scope engagement that turns a product idea or a new module into a buildable plan. We map the clinical workflow with the people who do the work, scope HIPAA, ONC and FDA software as a medical device obligations, inventory every EHR, lab, payer and device the product touches, record the architecture decisions, test the riskiest assumption with a prototype and hand you an estimate with its assumptions written down.
Scope your healthcare product discoveryFor founders, product leaders and CTOs planning a new healthcare product, module or customer segment. Updated September 26, 2026.
Roles, handoffs, exceptions and where the product changes the work
HIPAA, FTC HBNR, 42 CFR Part 2, ONC criteria and FDA device status
Every EHR, lab, payer and device, with standard, access path and owner
ADRs, a tested prototype, a phased backlog and an estimate with assumptions
Illustrative workflow · scope tailored to your environment
The short answer
Healthcare product discovery is the phase before build where a team confirms who the product is for, how it fits the clinical or operational workflow, which regulations apply, which systems it must exchange data with and what the first release must contain. It ends in documents you can act on: workflow maps, a regulatory scope memo, an integration inventory, architecture decision records, a tested prototype and an estimate. In healthcare, discovery matters more than in other markets because EHR access, FDA device status and HIPAA obligations can each change the architecture and the budget.
Why healthtech MVPs run late, and how discovery prevents itStart with the real problem
They are the EHR that exposes read-only FHIR resources when the workflow needs write-back, the triage feature that turns out to be device software under FDA rules, the state privacy law that applies to a wellness app outside HIPAA, the lab that only sends HL7 v2 over VPN, or the clearinghouse enrollment that takes weeks. Each of these can be found in a few days of structured discovery, and each costs months when found during build.
What we build
Six documents your team, investors and future vendors can use, whoever builds the product.
Current and target workflows for each role: clinicians, front desk, billers, care managers and patients, including interruptions, co-signature, handoffs and exceptions.
Which rules apply and what each requires of the software: HIPAA or the FTC Health Breach Notification Rule, 42 CFR Part 2, state health privacy laws, ONC criteria your customers need, and whether any feature is a device software function.
HIPAA compliant software developmentEvery system the product touches, with the standard, the access path, the vendor program, the data owner and the lead time to production credentials.
Healthcare interoperability servicesThe decisions that are expensive to reverse, written down with options and trade-offs: record model, tenancy, identity and consent, integration pattern, cloud and AI approach.
A clickable prototype of the riskiest journey, tested with the clinicians or patients who will use it, plus a technical spike where the risk is an API rather than a screen.
A first release sized to reach your next milestone, with later phases, exclusions, third-party costs and assumptions listed separately.
Estimate your healthcare productYour starting point
You have a thesis and early customers or investors. Discovery confirms the first workflow, the systems it must connect to and the regulatory path, so the MVP budget is real.
An existing product is adding e-prescribing, prior authorization, RPM billing or a new specialty. Discovery maps what changes in the data model, integrations and compliance scope.
You have a build quote or a platform choice and want the assumptions checked. Discovery tests the riskiest ones against sandboxes, documentation and your workflows.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
Shadow or interview the people who do the work, map current and target workflows per role, and mark where the product removes steps, adds review points or changes who is accountable.
Decide whether you are a covered entity, a business associate or outside HIPAA. Outside HIPAA, consumer health apps fall under the FTC Health Breach Notification Rule and state laws such as Washington's My Health My Data Act. Substance use disorder records bring 42 CFR Part 2.
If customers use certified health IT for CMS programs, list the 170.315 criteria in play, including the (g)(10) standardized API with USCDI v3 and US Core 6.1.0. For payer products, map CMS-0057-F API deadlines.
Screen each feature against FDA device software guidance and the four clinical decision support criteria in section 520(o)(1)(E) of the FD&C Act. If a feature is device software, plan for IEC 62304 lifecycle records and the Quality Management System Regulation that aligned 21 CFR Part 820 with ISO 13485 from 2 February 2026.
For each EHR, lab, pharmacy, payer, HIE and device: the standard (FHIR R4, HL7 v2 ADT, ORM, ORU, SIU, X12 270/271, 837, 835, NCPDP SCRIPT), the access program, sandbox availability, write-back support and production lead time.
Record model on FHIR or a relational model with a FHIR API, tenancy, identity and SMART on FHIR launch, consent, integration engine or platform, cloud services under a BAA and the AI evaluation approach.
Prototype the riskiest user journey and test it with real users. Where the risk is technical, run a spike against the EHR or payer sandbox to confirm the data is there.
Size the first release to your next milestone, sequence later phases and separate engineering effort from third-party fees, vendor lead times and clinical review time.
Compare your options
Discovery is a small fixed investment against the largest risks in healthcare software. This is what changes.
| Discovery first | Straight to build | Vendor pre-sales scoping | |
|---|---|---|---|
| Regulatory scope | Screened per feature for HIPAA, FTC, ONC and FDA | Found during build or customer review | Usually assumed |
| EHR and payer access | Programs, sandboxes and lead times confirmed | Discovered when integration starts | Listed as a dependency |
| Estimate quality | Built on a scoped backlog with written assumptions | Grows as unknowns appear | Sized to win the deal |
| User fit | Prototype tested with clinicians or patients | Tested after release | Demo-driven |
| What you keep | Maps, memo, register, ADRs, prototype, backlog | Code only | A proposal |
| Who can build afterward | Any team, including yours | The team that started | The vendor |
Discovery deliverables are yours. Teams use them to brief an in-house team, a partner of their choice or investors.
Expertise is in the decisions
A symptom checker, a risk score or a dosing aid can be device software; a scheduling tool is not. Screening each feature lets you ship the non-device parts first and plan the records the device parts need.
Many EHR FHIR APIs are read-heavy. If the workflow needs to write orders, notes or results, confirm the endpoint, the vendor program and the customer approval in discovery, or redesign the workflow.
A FHIR-native store simplifies APIs and certification; a relational model with a FHIR API layer can suit heavy reporting. Decide with the integration inventory and certification scope on the table.
The regulatory scope memo gives engineering answers and open questions. Your counsel confirms legal conclusions and the FDA decides device status, including through the pre-submission program where needed.
We map workflows and test prototypes with your clinicians. Clinical protocols and decision logic are specified and approved by them.
Timeline
Most discovery engagements run 3 to 6 weeks. The number of user roles, integrations and regulatory questions sets the length.
Goals, users, constraints and the decision discovery must support; access requests opened.
Workflow sessions, regulatory screening and the integration inventory run in parallel.
Architecture options, ADRs, the prototype and any sandbox spike.
Backlog, roadmap, team plan and estimate reviewed with decision makers.
Delivered work
Client names are withheld; each is a real engagement. Our open-source healthcare engineering is public on GitHub.
Designed and prototyped a fax inbox, routing and send workflow for a US billing operation, proving the workflow and interface before a live fax provider was connected.
Found in discovery that a shared database was ruled out by data-protection law, and designed a federated exchange so every hospital's patients reach the same tumor board without records leaving home.
Defined structured pain capture with location, character and impact instead of a single score, so the data carries clinical weight for clinicians and payers.
A reference record model and SMART on FHIR API we use to test architecture options quickly; it passed 47 of 47 ONC (g)(10) SMART App Launch standalone patient tests in Inferno.
From discussion to delivery
Agree the goal, the users, the constraints and the decision discovery must support.
Workflows, regulatory scope and integrations investigated in parallel with your team.
ADRs written, the riskiest journey prototyped and tested, sandbox spikes run.
Backlog, roadmap and estimate presented to decision makers, with every artifact in your hands.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↗It is a short, structured phase before build that defines users and workflows, screens regulatory obligations, inventories integrations, records architecture decisions, tests a prototype and produces an estimate. It exists to find the expensive unknowns while they are still cheap to change.
Usually 3 to 6 weeks. A single workflow with one EHR integration sits at the short end; a multi-role product with several integrations and an FDA question sits at the long end.
Discovery is a fixed-scope engagement priced from the number of workflows, user roles, integrations and regulatory questions in scope. We quote it as a fixed price after a first call.
Clinical workflow maps, a regulatory scope memo, an integration inventory, architecture decision records with a C4 diagram and PHI data flow, a tested prototype, a phased backlog, a roadmap and an estimate with its assumptions.
No. The deliverables are yours and written so any team can use them. Many clients continue with us for the build; others brief their in-house team or another partner.
We screen each feature against FDA device software guidance and the four clinical decision support criteria in section 520(o)(1)(E) of the FD&C Act, and list which features look like device software functions and why. Your regulatory lead confirms the conclusion, and for close calls we prepare the technical input for an FDA pre-submission.
HIPAA applies if you are a covered entity or handle PHI on behalf of one as a business associate. Direct-to-consumer apps outside HIPAA still fall under the FTC Health Breach Notification Rule and state laws such as Washington's My Health My Data Act. Discovery maps which applies to each data flow.
Every system the product must exchange data with: EHRs such as Epic, Oracle Health and athenahealth, labs, pharmacies, HIEs, payers and clearinghouses, and devices. For each we confirm the standard, the vendor access program, sandbox access, write support and production lead time.
An ADR is a short document in your repository that records one significant decision, the options considered, the trade-offs and the consequences. Discovery produces ADRs for the record model, tenancy, identity, consent, integration pattern and cloud services, so future engineers know why the system is shaped the way it is.
No. Discovery uses de-identified or synthetic examples, screen recordings of current workflows and interface specifications. Where a sandbox spike needs data, we use the vendor's test patients.
Yes. For an existing product, discovery focuses on the new module, customer segment or integration and maps its impact on the current architecture, data model and compliance scope.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
