Executive Summary
The current ProspectRX prototype enriches uploaded provider files with National Provider Identifier registry data and exports structured results. This case study explores how that focused utility could evolve into an observable provider-data workflow with supported-source collection, job monitoring, and governed exports.
The proposed product would consolidate fragmented directory research, NPI lookup, spreadsheet cleanup, and file formatting into one repeatable workflow.
My role: Product strategy, requirements definition, workflow design, risk framing, and portfolio narrative.
- 01Select a provider specialty or enter a supported directory URL.
- 02Configure collection and enrichment behavior.
- 03Run a background job.
- 04Monitor progress and cancel when needed.
- 05Review result counts and export CSV, Excel, or JSON.
The current implementation is automation-led, not AI-led. Future AI should support classification, normalization, anomaly detection, and workflow assistance while preserving traceability and human review.
Business Problem
Current user effort
- Find provider records across specialty-specific directories.
- Open profile pages and locate or verify NPI information.
- Copy records into a spreadsheet.
- Normalize names, locations, provider types, and taxonomy values.
- Remove duplicates and incomplete records.
- Repeat the process whenever a campaign or research request changes.
- Explain where each record came from and when it was collected.
| Business problem | Impact |
|---|---|
| High manual effort | Researchers browse and manipulate spreadsheets instead of acting on the data. |
| Inconsistent quality | Operators apply different naming, filtering, and validation conventions. |
| Low repeatability | Manual processes are difficult to configure, compare, schedule, or reproduce. |
| Slow time to action | Business users wait for specialists to prepare the right file format. |
Why now
Healthcare teams increasingly need provider intelligence by specialty, geography, and entity type. Public data exists, but remains fragmented across directory pages and registry files.
Business Opportunity
ProspectRX helps healthcare teams create targeted, NPI-enriched provider datasets in a repeatable workflow with visible job status and export-ready output.
Differentiation hypothesis
- Healthcare-specific taxonomy and provider-type workflows
- NPI-aware enrichment rather than generic page extraction
- Simple specialty selection instead of requiring technical URL knowledge
- Transparent progress, counts, errors, and source information
- Export controls aligned to business workflows
The positioning prioritizes explicit source-access, provenance, and usage guardrails over extraction volume.
Goals and Non-Goals
| Business goal | Rationale |
|---|---|
| Reduce time to produce a targeted provider list | Gives research and growth teams faster access to usable data |
| Improve provider-record completeness | NPI, taxonomy, organization, and location fields support downstream use |
| Make collection repeatable | Saved workflows reduce variation between requests and operators |
| Increase trust in outputs | Source, timestamps, validation, and errors make results traceable |
| Create a paid automation foundation | Usage, export, and team controls enable future packaging |
Next-release objectives
- Create and save a specialty or provider workflow without knowing a technical URL.
- Run jobs and understand queued, running, complete, cancelled, and failed states.
- See provider counts, enrichment counts, and records requiring review.
- Export a filtered, documented dataset for spreadsheet or system use.
- Distinguish verified registry data from fallback, inferred, or synthetic demonstration data.
Non-goals
- Replacing a CRM, marketing automation platform, or outreach sequencer
- Providing clinical advice, patient data, diagnosis, or treatment information
- Guaranteeing every provider is active, accepting patients, or reachable
- Collecting from websites regardless of terms, controls, or robots directives
- Claiming universal source coverage or guaranteed data accuracy
- Building an autonomous outreach or decision-making AI agent
Target Users and Stakeholders
| User | Job to be done | Desired outcome |
|---|---|---|
| Healthcare growth or business-development researcher | Create a focused specialty and geography list quickly | Usable prospecting dataset |
| Healthcare recruiting or network-development analyst | Find and enrich organizations or professionals consistently | Searchable, NPI-aware list |
| Data operations specialist | Configure, run, audit, and export recurring requests | Repeatable and observable jobs |
| Product or engineering administrator | Understand failures and recover safely | Reliable operations and clear failure states |
DACI
| Role | Who | Responsibility |
|---|---|---|
| Driver | Product manager / portfolio owner | Own problem definition, priorities, and outcome measurement |
| Approver | Product / business owner | Approve scope, release readiness, and risk |
| Contributors | Engineering, design, data, and compliance | Provide feasibility, usability, quality, and risk input |
| Informed | Research, growth, recruiting, and support | Receive limitations, release notes, and operating guidance |
Scope
In scope
- Specialty-based workflow setup and supported directory URL validation
- Provider-list collection as a background job
- NPI import from CSV and supported URL-download flows
- NPI lookup and enrichment
- Filters for specialty, provider type, state, entity type, and record limit
- Progress, job-state, cancellation, and failure visibility
- CSV, Excel, and JSON export
- Export templates and custom column selection
- Data provenance and quality indicators in the target state
- Operational guardrails for respectful source access
Out of scope
- Patient records or protected health information
- Clinical decision support
- Contact verification or identity resolution beyond provider data
- Automated email, calling, messaging, or campaign execution
- CRM synchronization in the first release
- Multi-tenant billing and entitlements in the first release
- Fully autonomous source discovery
Prototype Evidence and Constraints
Portfolio disclosure: The live demo currently exposes the provider-file and NPI lookup workflow. The remaining capabilities come from prior implementation notes and are proposed requirements unless demonstrated in the public prototype.
Reported prototype capabilities
- Dashboard views for workflows, jobs, statistics, and recent activity
- Two logical stages: provider-list collection and NPI detail enrichment
- Specialty selection that can populate supported NPIDB URLs
- Configurable page limits, request pacing, and concurrency controls
- PostgreSQL-backed workflow, job, and data models
- Sequential background queue with pending, running, completed, failed, and cancelled outcomes
- Cleanup for jobs that remain running longer than 30 minutes
- NPI CSV loading with common Version 1 and Version 2 column mapping
- Search by specialty, state, provider type, and entity type
- Essential, Contact, Professional, and Complete export templates
- Custom columns and CSV, Excel, and JSON export
Limitations to disclose
- Some portfolio-environment workflows use demonstration records rather than verified live-source retrieval.
- Demonstration and fallback records must be labeled and excluded from verified production exports.
- Include inactive is not yet a true registry-status filter.
- Export preview currently uses sample data instead of the selected live result set.
- Several settings are UI state rather than persisted user preferences.
- User tables exist, but the visible workflow is not a complete authorization model.
- Email, API, and webhook options exist in the UI model; direct download is the implemented path.
- The product should not promise universal directory support or unlimited collection.
Business Requirements
Must items define a credible production MVP. Should and Could items follow after core trust and reliability. Won't now items are explicitly deferred.
| ID | Requirement | Priority | Success signal |
|---|---|---|---|
| BR-001 | Create a repeatable workflow by specialty or supported URL. | Must | New users save a valid workflow without support |
| BR-002 | Run a workflow asynchronously without keeping the page open. | Must | State and results persist after refresh |
| BR-003 | Show actionable job state, progress, completion expectations, and failure reasons. | Must | Fewer stuck-job support questions |
| BR-004 | Cancel an active or queued job. | Must | Cancelled jobs stop output and remain clearly labeled |
| BR-005 | Enrich eligible providers with NPI data and distinguish match outcomes. | Must | Enrichment and unmatched counts are visible |
| BR-006 | Import supported NPI files and monitor load status. | Must | Valid files show counts; invalid files fail clearly |
| BR-007 | Filter and export only required records and columns. | Must | Exports match selected filters and columns |
| BR-008 | Preserve source, collection time, and quality context. | Must | Reviewers can explain record provenance |
| BR-009 | Enforce respectful source-access policies and avoid unsupported promises. | Must | Limits are respected and blocked sources surfaced |
| BR-010 | Expand specialty taxonomy through configuration. | Should | Mappings can be added without workflow redesign |
| BR-011 | Provide saved views or reusable export presets. | Should | Recurring requests take less setup time |
| BR-012 | Add role-based access and workspace separation before team rollout. | Should | Users access only permitted data |
| BR-013 | Add AI-assisted normalization, deduplication, and review explanations. | Could | Review time falls without reducing precision |
| BR-014 | Deliver auditable results through API or webhook after direct export is reliable. | Could | Downstream systems receive replayable packages |
| BR-015 | Do not initiate outreach or make clinical or eligibility decisions. | Won't now | Scope remains data operations |
Business Rules
- 01Every job references one saved workflow configuration.
- 02A workflow needs a valid source or supported specialty mapping before it runs.
- 03A job is processed at most once at a time; the MVP queue is sequential.
- 04Queued or running jobs can be cancelled; completed jobs cannot.
- 05Completed jobs report provider count, enrichment count, and enrichment rate.
- 06A valid NPI key is exactly 10 numeric digits.
- 07Registry, source-extracted, inferred, and synthetic data are never presented as equivalent.
- 08Active status requires a reliable status field and documented freshness date.
- 09Export filters apply before generation and appear in metadata or a companion manifest.
- 10Unsupported, inaccessible, malformed, or unauthorized sources fail explicitly.
- 11Rate limits, source terms, and privacy requirements take precedence over speed.
- 12AI-generated values remain labeled, evidence-linked, and reviewable before verified export.
Success Measures
North-star outcome
Verified, export-ready provider records produced per successful workflow, measured with a quality gate—not raw rows alone.
Pilot targets are hypotheses until real usage data establishes a baseline. They should not be presented as observed performance.
| Metric | Definition | Pilot target |
|---|---|---|
| Time to first usable export | Valid workflow submission to successful export | Baseline, then reduce 50% |
| Job success rate | Completed jobs / started jobs, excluding cancellations | ≥ 95% |
| Enrichment coverage | Valid NPI matches / eligible providers | ≥ 85%, source-dependent |
| Verified-record precision | Sampled exports matching authoritative fields | ≥ 98% |
| Export success rate | Successful exports / attempts | ≥ 99% |
| Repeat-workflow adoption | Users running a saved workflow more than once | ≥ 40% of pilot users |
| Manual correction rate | Sampled rows requiring correction | Baseline, then reduce |
| Cancellation responsiveness | Request to cancelled state | P95 under 30 seconds |
| Data freshness compliance | Verified exports within declared freshness window | 100% |
Risks, Compliance, and Trust
| Risk | Impact | Mitigation |
|---|---|---|
| Source terms are violated | Legal, reputational, and operational risk | Approved sources, rate limits, terms review, and source disablement |
| Registry data is stale | Poor targeting decisions | Show source date, freshness, match status, and limitations |
| Demonstration data appears verified | Severe trust risk | Label it prominently and exclude it from verified exports |
| Duplicate or mismatched providers | Inflated lists and wasted outreach | Use NPI keys first, then cautious reviewed deduplication |
| Provider data is treated as patient data | Privacy and compliance risk | Prohibit PHI and limit scope to provider/business data |
| Long-running jobs become stalled | Lost work and low trust | Durable state, timeouts, retries, and recovery controls |
| Concurrency harms a source | Blocks and throttling | Conservative defaults, rate limits, backoff, and visibility |
| AI creates plausible errors | Silent data corruption | Grounding, confidence, evidence, approval, and audit logs |
| Exports contain unexpected fields | Privacy or processing risk | Explicit columns, schema versions, and live preview |
ProspectRX is a provider and business-data operations tool—not a clinical system. External commercialization requires legal and privacy review of source terms, licensing, acceptable use, retention, and access.
Product Strategy and Roadmap
Now
Trust and core value
- Reliable supported-source collection
- Real NPI matching and enrichment
- Verified, unmatched, and fallback labels
- Durable state, cancellation, retry, and recovery
- Live previews and export manifests
- Persisted settings and workflow history
- Source-access guardrails
Next
Repeatability and teams
- Saved export presets and filtered views
- Improved deduplication and validation
- More taxonomy mappings and source adapters
- Workspace roles and access control
- Signed API and webhook result packages
- Approved scheduled runs with limits
Later
Bounded AI assistance
- Natural-language setup translated into explicit filters
- Taxonomy and organization normalization suggestions
- Evidence-backed duplicate and anomaly review
- Quality summaries for missing, conflicting, or stale fields
- User-approved schema mapping for unfamiliar files
AI should follow deterministic lineage and quality metrics. Otherwise it can make the workflow look easier while making the output less trustworthy.
Prioritization Rationale
MoSCoW is used instead of RICE because reliable reach, retention, and effort data do not yet exist.
- Trust and correctness before scale.
- Observable execution before broader automation.
- Export usefulness before integrations.
- Deterministic quality before AI generation.
- Team and commercial features after repeat usage is proven.
What I Would Validate Next
- Who is the first pilot customer: growth, recruiting, network development, or research?
- Which sources are approved for collection and redistribution?
- Is this internal operations, a managed data service, or self-serve software?
- What freshness window applies to each use case?
- Which fields are required for a verified export?
- What retention policy applies to imported NPI files and exports?
- Are user-provided sources allowed, or only a curated catalog?
- What review threshold applies to unmatched, duplicate, or AI-suggested records?
- What usage limits are appropriate for the first pilot?
- Which CRM or downstream destination matters most after direct export?
Product Decisions and Tradeoffs
I reframed a provider-data automation prototype as a trustworthy healthcare data workflow. I separated the business outcome—verified, export-ready provider lists—from the underlying collection and enrichment mechanisms. I defined explicit job states, data-quality labels, governance boundaries, success metrics, and a staged AI roadmap instead of claiming AI where the MVP did not use it.
Product judgment demonstrated
- Understand the user problem—not only the feature.
- Separate current capability from future vision.
- Treat provenance and compliance as product requirements.
- Measure quality, not only volume.
- Introduce AI where it improves decisions and review, not where it creates unbounded risk.