From clarity to measurable impact. I connect customer needs, business priorities and technical execution to build products—and the teams that deliver them.
Prescription: From prescription to the next refill.
Clinical and billing checks may run in parallel. Controlled-substance checks and reporting are conditional branches, not a universal extra step.
Receive & prepare. Prescription, patient and medication details enter intake. New Rx, transfer and renewal are separate entry paths. Supporting account
Coverage & billing. Coverage and cost information are checked; early billing is a proposed sequencing branch. Early billing may overlap verification. Reversal or rebill is a controlled human/system action, not AI authority. Supporting account
Order & readiness. The patient confirms applicable price and order details; readiness checks govern release. Customer ordering and pharmacy release are distinct states. Supporting account
Dispense & deliver. Final checks, dispensing and delivery carry the prescription to the patient. Controlled-substance reporting is tied to applicable dispense/reporting requirements, not universally to delivery. Supporting account
Care, report & renew. Patient questions, required reporting and renewal needs feed the next cycle. Care runs across all stages. Reporting and refill/renewal are parallel follow-through paths. Supporting account
AI-assisted care: One contact. Context that leads to care.
Production console capabilities and the public agentic design study have separate evidence. Amazon Pharmacy SMS/OTP authentication launched. Automated wrap-up is a separate capability whose delivery status is unspecified.
Contact & verify. A customer contacts Amazon Pharmacy care; an automated text/SMS code replaces the former manual verification step. Amazon Pharmacy customer-care authentication. Separate from Cigna health-plan enrollment and Kafka work. Supporting account
Assemble context. Relevant order, prescription and prior-contact context becomes a useful brief. Retrieval and summarization help the representative; they do not grant authority. Supporting account
Review & decide. A representative reviews the brief and chooses a permitted next step. End-to-end product leadership and key decisions span capabilities; individual implementation roles and shipped outcomes are specified separately. Supporting account
Act & reconcile. The permitted action is executed and its actual result checked. Clinical escalation and billing explanations do not imply autonomous clinical or financial writes. Supporting account
Explain & close. The customer receives an explanation and an appropriate next step. Different capabilities’ outcomes are measured separately. Supporting account
Evaluate & improve. Quality review and feedback improve the next contact. Human review gates knowledge updates and any deployment. Supporting account
Procurement: From catalog setup to a reconciled order.
Hosted catalog, PunchOut and quote requests are alternative entry paths. They converge at approval and ordering; every purchase does not require a quote.
Onboard & configure. Buyer and supplier agree account setup, content and integration requirements. Supplier and customer changes both re-enter configured review. Supporting account
Browse & build need. A buyer uses a hosted catalog or a PunchOut shopping experience. Direct catalog shopping and PunchOut are distinct paths; Punch-in is separately preserved. Supporting account
Source & quote. When quoting is needed, the seller matches demand and communicates price and terms. Quote creation and price-lock terms are distinct from award; award triggers inventory reservation. Quoting is optional; direct catalog purchasing can bypass this branch. Supporting account
Award & order. Quote award triggers inventory reservation. After award, an award receipt is sent through integration. Order placement uses the applicable ordering interface. Award-triggered reservation and post-award integrated receipt apply to the quoting path. Direct purchases retain their applicable approval/order path. Supporting account
Fulfill & inform. The seller fulfills the order and communicates its status. Retain the existing case’s quote controls and arithmetic demonstration. Supporting account
Invoice & learn. Invoice, receipt and order context support reconciliation and future improvement. Feedback can improve catalog data, unit interpretation or partner onboarding. Supporting account
Payer & PBM: From plan design to care and reconciliation.
This is a capability map with branching paths, not a mandatory sequence. Employer/group and individual/family enrollment differ; medical, pharmacy and rebate processing have separate contracts.
Client & plan. Plan configuration includes network participation and preferred-pharmacy choices where applicable at Rx level. Group and individual/family market paths remain distinct. Pharmacy network contracting and clinical governance have different responsibilities. Supporting account
Enroll & identify. Open-enrollment intake, active enrollment setup and premium payment connect the IFP experience. Programs included ACA/Obamacare and Cigna participation in state-sponsored plans. Specific programs may differ. Supporting account
Access & experience. A member finds care, checks benefits and uses digital or assisted service. Networks, digital experience, ID cards and ongoing care remain continuous capabilities. Supporting account
Medical ↔ pharmacy. Medical and pharmacy claims follow different paths; a shared drug catalog supports pharmacy data and rule use. Formulary, step therapy, exclusion, prior authorization and MAC lists are nested catalog capabilities. FDA status is distinct from list inclusion. Supporting account
Pay, explain & rebate. Rebate finance connects PBM/manufacturer contracts, pharmacy-claims calculations, invoicing, reconciliation and client sharing. Separate from provider payment/835 and member EOB. Sharing included 50/50 and fixed-sharing options; no other terms are implied. Supporting account
Report, change & renew. Operational and financial feedback informs corrections, product changes and renewal. Actuarial/reporting, client feedback, IFP changes and member renewal remain connected parts of the product-leadership journey; specific decisions, delivery roles and outcomes are described separately. Supporting account
Start with the organization. Explore the teams, product decisions and work behind it.
2022–now
From safer pharmacy to connected commerce.
Amazon Business (2022–2024), then Amazon Pharmacy (2024–present). Punchout across 100-plus procurement systems; reporting to 50 states and DC; three generative-AI agents.
Senior Product Manager – Technical
Explore Amazon →
Senior Product Manager – Technical · 2022–now
The strategy addressed onboarding and customer adoption.
The strategy brought five levers together around one adoption target everyone could see.
01 Connected
Punch out, shop, return.
Cart handoff
Cart handoff:the cart returns to procurement for approval and a purchase order.
Start in procurement
Shop the marketplace
Cart returns for approval
more than100e-procurement systems
I owned Punchout across them.
02 Slowed
Too few connected users were buying.
ConnectedBuyingtoo few
Activationand time to first order
I addressed adoption and onboarding.
03 Decided
Five levers, each measured.
SalesVertical-specific integration goalsSuggested measure (illustrative): Integrated accounts by vertical
Professional servicesA shared launch-readiness onboarding frameworkSuggested measure (illustrative): Days to first order
Source: this case study. Suggested lever measures are illustrative.
1 Amazon Business · 2022–2024. Weekly Punchout insights ran in weeks six to twelve of 2024.
Amazon Business · Integrated Quoting
From a quote request to an order.
Volume pricing becomes an orderable commitment after the quote is won.
Requestvolume pricing
Win firstthen lock + reserve
After orderreconciliation / invoice
→→
After the quote is won ↓
→→
Commercial workflow. Local eligibility and unit conversion examples are illustrative, not measured results. Select a labeled step for an overview and process details.
Read the complete process
Quote request
Enterprise buyers request quotes from Amazon Business and third-party providers inside their sourcing platform. The response path makes product match, available inventory and the requested unit explicit.
Process note: The request form is simplified. It contains no buyer identifier, historical conversion rate or recorded quote.
Volume pricing
Catalog match and availability inform a suitable response. A pack price and an each price cannot be compared without conversion factors. Illustrative arithmetic: $4.25 × 12 ÷ 6 = $8.50 per case of 12.
Process note: Illustrative eligibility: more than 1,000 units OR more than $10,000. Exactly 1,000 units and $10,000 does not meet either strict threshold. The existing local calculator remains the place to try inputs.
Quote won
After a quote is won, the workflow locks price and reserves inventory while the customer orders. This is the commercial transition between quote response and the order path.
Process note: No win rate, completed pilot, lock duration or reservation duration is asserted.
Lock price + reserve
Price lock and inventory reservation follow quote win and support the customer while they order. The two objects in the illustration are parallel commitments in this same state.
Process note: The lock and stock specimens show function. They do not imply a specific time limit or inventory quantity.
Submit the order
The customer submits the order through Ordering API/XML. This order-submission role follows the won quote and its price lock and inventory reservation.
Process note: The XML page is a conceptual artifact; it is not an actual API schema or customer payload.
Post-order follow-through
Reconciliation/Invoice API supports the post-order workflow. Its role is distinct from Ordering API/XML, which handles the submission of the order.
Process note: The invoice specimen is illustrative. No invoice amount, fulfillment rate or reconciliation outcome is added.
The task
Daily reports to every state program, each with its own format
In parallel:
Rules
State-specific formatting and delivery over a secure pipeline
In parallel:
Security
Highest-tierhealth-security classification for PHI transfers
Rollout
Phased state by state
Exceptions
Failures and rule changes routed to a person
Workstream · illustrative controls
A customer assistant that resolves 78% of chats without a person
Explore the request, the response, and where a person takes over.
Illustrative ordering requires separate authorization
The customer assistant answered common questions using context and retrieval, with a summary for the representative when the issue needed a person.
Authority:Illustrative policy: consequential actions require separate authorization.
Explanatory condition and selected responsibilities reconstructed from the source boundaries; not an additional observed event, tool execution or measured result.
Inspect the selected source evidence
Explore the request, the response, and where a person takes over.
↶
Feedback returns to evaluation. Proposed policy: compare actual outcomes before expanding scope.
Illustrative controls; not production telemetry or measured outcomes.
Inspect operating-control evidence
Explore the request, the response, and where a person takes over.
Read all conditions, operating controls and evidence boundaries
Explore the request, the response, and where a person takes over.
Routine question
Retrieve context for a useful answer. The customer assistant answered common questions using context and retrieval, with a summary for the representative when the issue needed a person.
Authority: Illustrative policy: consequential actions require separate authorization.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Order requested
Confirm authority before an order. In this illustration, guidance continues to a separately authorized ordering step.
Authority: Illustrative policy: verify authority before transacting.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Handoff incomplete
Verify the handoff outcome. This illustrative control verifies handoff completion and carries unresolved context until a person accepts the work.
Authority: Illustrative policy: carry unresolved context until a person accepts.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Illustrative evaluation
Resolution and handoff outcomes. Proposed policy: compare actual outcomes before expanding scope.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Illustrative handoff policy
Transfer attempt and accepted ownership. Proposed policy: verify completion and accepted ownership.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Illustrative change review
Evaluate candidate corrections. Proposed policy: review evidence before changing routes or tools.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Workstream · illustrative controls
A clinical copilot rebuilt when 15-second latency made it unusable
Explore the request, the response, and where a person takes over.
Clinical authority stays with the person
Select a condition · explanatory reconstruction
Case support
Human authority
Validation control
Workstream · illustrative controls · Cited support
Useful support arrives during the work.
The copilot supported clinical operators with curated procedures, case summaries and next-best actions.
Authority:The operator evaluates and acts on the support.
Explanatory condition and selected responsibilities reconstructed from the source boundaries; not an additional observed event, tool execution or measured result.
Inspect the selected source evidence
Explore the request, the response, and where a person takes over.
Illustrative controls; not production telemetry or measured outcomes.
Inspect operating-control evidence
Explore the request, the response, and where a person takes over.
Read all conditions, operating controls and evidence boundaries
Explore the request, the response, and where a person takes over.
Cited support
Useful support arrives during the work. The copilot supported clinical operators with curated procedures, case summaries and next-best actions.
Authority: The operator evaluates and acts on the support.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Decision required
A recommendation is not the decision. The source workflow ends with the operator’s disposition. The assistant does not acquire clinical authority because it generated a next best action.
Authority: Clinical authority remains with the qualified person.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Latency problem
Validate response delivery. This illustrative control checks latency and accuracy before expanding the workflow.
Authority: Illustrative policy: validate latency and accuracy before expansion.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Illustrative validation
Latency and accuracy. Proposed policy: check response quality alongside speed.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Operator ownership
Procedures and decision context. The operator evaluates supporting information and decides.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Illustrative redesign review
Response delivery candidates. Proposed policy: compare latency and accuracy before reuse.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Production billing workstream
A claims and billing agent that explains 800+ rejection codes
Explore the request, the response, and where a person takes over.
Allowed billing actions · clinical edits to pharmacist; prescription edits to technician
Select a condition · explanatory reconstruction
Amazon Pharmacy · production after pilot and ramp-up
A rejection becomes a next action.
Billing support after prescription typing, with edits routed to the right person.
100k+prescriptions / month · scope
Post-typingplatform integration
Human approvalclinical / DUR edits
→
Next action depends on the rejection
Permitted billing action
Prescription edit needed
Clinical edit needed
↶
Staff edits return to billing. The agent can suggest further changes.
Workflow scope is not an accuracy or safety measure. Simplified process specimens; no patient data. Select a labeled step for an overview and process details.
Read the complete process
Prescription typed
The billing agent is integrated into the Amazon Pharmacy platform after prescription typing. The figure follows billing work from rejection context to a permitted action or staff handoff.
Process note: The prescription sheet is a conceptual specimen, not a patient record or a product screenshot.
Interpret the rejection
The agent interprets rejection knowledge alongside authorized billing context and rule limits. The returned context informs the next allowed billing action or the relevant human handoff.
Process note: The illustrated rule rows show categories of information; they do not invent a decision score or an accuracy result.
Allowed billing action
Billing workflow examples include correcting a 30-day supply to an allowed 28 days, updating insurance and resubmitting, or refiling an approved 30-day quantity when a 90-day request exceeds the insurance limit. Other paths support prior authorization, compare coupon and insurance pricing, or communicate the next refill date.
Process note: These are workflow-specific billing permissions. They do not give the agent authority to approve a clinical or DUR edit.
Prescription edit
Brand/generic prescription and DAW edits go to a technician. A technician refiles after making the required edit; the agent can then suggest further changes based on the returned billing state.
Process note: The staff branch is conditional. It is not an extra mandatory step for every prescription.
Clinical / DUR edit
Clinical and DUR edits go to a pharmacist for manual verification and approval. The agent supports the billing workflow while clinical judgment and approval remain with the pharmacist.
Process note: Production rollout establishes deployment scope. It does not establish AI clinical decision authority, accuracy or safety performance.
Refile and inspect
A technician or pharmacist refiles after making the required edit. The agent inspects the returned billing context and can suggest further changes. This closes the work loop without transferring clinical approval to the agent.
Process note: The return arrow explains the work loop. It does not imply automatic learning or an unreviewed change to prescribing.
Inspect original source responsibilities
Claim support
Workflow-specific permissions
Operating controls
Production billing workstream · Explain rejection
Interpret the rejection and take the allowed billing action.
The billing workflows are in production after pilot and ramp-up. The agent interprets rejection knowledge and can correct a 30-day supply to the allowed 28 days, update insurance and resubmit, or refile an approved 30-day quantity when a 90-day request exceeds the insurance limit. Clinical/DUR edits go to a pharmacist for manual verification and approval; brand/generic prescription and DAW edits go to a technician. Prior authorization goes to a PA bot for CoverMyMeds filing, follow-up after four unresolved days and customer notification after approval. Other paths compare coupon and insurance pricing or communicate the next available refill date. I integrated the billing agent into the Amazon Pharmacy platform after prescription typing and launched the prescription flow: a technician or pharmacist refiles after making the required edit, and the agent suggests further changes. The work affected more than 100,000 prescriptions per month at Amazon Pharmacy.
Authority:Rule-bound billing actions preserve pharmacist and technician approval boundaries.
Explanatory condition and selected responsibilities reconstructed from the source boundaries; not an additional observed event, tool execution or measured result.
Inspect the selected source evidence
Explore the request, the response, and where a person takes over.
↶
Feedback returns to evaluation. Proposed policy: record breaches and route them for review.
Illustrative controls; not production telemetry or measured outcomes.
Inspect operating-control evidence
Explore the request, the response, and where a person takes over.
Read all conditions, operating controls and evidence boundaries
Explore the request, the response, and where a person takes over.
Explain rejection
Interpret the rejection and take the allowed billing action. The billing workflows are in production after pilot and ramp-up. The agent interprets rejection knowledge and can correct a 30-day supply to the allowed 28 days, update insurance and resubmit, or refile an approved 30-day quantity when a 90-day request exceeds the insurance limit. Clinical/DUR edits go to a pharmacist for manual verification and approval; brand/generic prescription and DAW edits go to a technician. Prior authorization goes to a PA bot for CoverMyMeds filing, follow-up after four unresolved days and customer notification after approval. Other paths compare coupon and insurance pricing or communicate the next available refill date. I integrated the billing agent into the Amazon Pharmacy platform after prescription typing and launched the prescription flow: a technician or pharmacist refiles after making the required edit, and the agent suggests further changes. The work affected more than 100,000 prescriptions per month at Amazon Pharmacy.
Authority: Rule-bound billing actions preserve pharmacist and technician approval boundaries.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Change requested
Route clinical and prescription edits to the right person. Clinical/DUR edits require pharmacist verification and approval. Brand/generic prescription and DAW edits go to a technician. Prior authorization goes to the PA bot for filing, follow-up after four unresolved days and approval notification.
Authority: The billing agent does not make autonomous clinical or prescription edits.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Guardrail breach
Record and review a breach. This illustrative breach-review control records safety exceptions and routes them for review.
Authority: Illustrative policy: review the breach before proceeding.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Illustrative breach review
Record safety exceptions. Proposed policy: record breaches and route them for review.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Workflow-specific authority
Pharmacist, technician and PA workflow. Refill-too-soon communicates the next fill date; coupon and insurance prices are separate billing paths.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Illustrative experiment review
Prompt, model and guardrail candidates. Proposed policy: evaluate candidate prompt, model and guardrail changes before reuse.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
Amazon Business · 2022–2024 · Enterprise commerce
Key work
Punchout across 100-plus procurement systems
Ran weekly Punchout business-review insights, weeks 6–12 of 2024
procurement integrations, quoting and catalog capabilities
Select a process step for a short overview, then open its details. The comparison is illustrative; the historical totals above describe the investigation.
Read the complete process
Account for both incoming streams
The incoming streams include four COBA files and eight files from Emdeon. COBA identifies the CMS claim-file stream; Emdeon processes VA claims. Received-file metadata provides the starting point for the reconciliation control.
Process explanation (illustrative guidance): Keep received files visible even when a later processing step pauses or fails. The four comparison rows in this figure are illustrative records, not a historical batch.
Give every file a traceable identity
The delivered audit table captures EDI 837 metadata: file name, unique ID, total claims and claim ICN numbers. Adjudicated claims retain the source file’s unique ID, allowing the received inventory to be compared with the processed inventory.
Process explanation (illustrative guidance): Use the same source-file identifier on both sides of the comparison. This file ID is distinct from the claim ID used for image retrieval in the separate Paper-to-EDI project.
Received does not always mean processed
The daily audit compares claims received with claims processed, using the source-file identifier retained on adjudicated claims. A paused upstream file-processing step can leave an entire file unprocessed. The illustrated missing row demonstrates that distinction; it does not depict a measured failure rate.
Process explanation (illustrative guidance): Investigate an unmatched record before treating it as an error or a completed claim. After recovery, confirm the processing record rather than closing the item merely because a file was received.
Make the unresolved work visible
A Tableau dashboard provides visibility into claims fallout from the received-versus-processed comparison. The visual here is a simplified explanation of the control, not a screenshot of a production dashboard.
Process explanation (illustrative guidance): Keep unresolved items visible for investigation. Detection and recovery are separate events; a report finding does not itself process a claim.
Process the missing delta
The expanded 20-million-claim investigation identified 300,000 missing claims worth about $10M in unprocessed claim value. The business processed the delta. These are historical investigation totals, not monthly volume, ongoing fallout rates or savings.
Process explanation (illustrative guidance): Confirm recovery against processing records. The before/after switch shows an illustrative unmatched file gaining a processed match, not a new quantified result.
Keep comparing, every day
The investigation led to a daily audit comparing received and processed claims. The audit table, source-file identifier and Tableau reporting make future fallout visible for investigation.
Process explanation (illustrative guidance): Recheck unresolved work after a repair and keep the received and processed inventories aligned. This control is separate from the Microsoft BizTalk replacement and the claims-engine replacement.
Reduced motion: select a step or compare the two static states.
Directed an enterprise transaction data platform with a 14-person team and an $18M budget across 15 products and 4 portfolios, and secured $24M in annual funding. Owned enterprise MDM (Reltio) strategy and launched a master identifier service that has created about 4 million unique IDs.
Identified 300,000 missing claims worth about $10M through a 20-million-claim, 50 GB analysis and put a daily reconciliation audit in place; wrote a provider-match script and automated it with SSIS.
Connected integration and migration requirements to consumer needs, data quality, acceptance and production readiness.
Preview a contribution below; open the organization above for full work and cases.
2016–2018
A connected future for retail pharmacy.
$25M point-of-sale and pharmacy-management migration, 7-person team.
Manager, Business Systems Analysis
Explore McKesson →
Manager, Business Systems Analysis · 2016–2018
In parallel:
Daily work
Ring up a sale; fill a prescription; keep the store running
In parallel:
Model
On-premise cost is the technician visit nobody invoices
De-risk
Reverse-engineer the existing POS logic before moving it
Build
New transaction flows and POS wireframes with UI teams
Run
Post-launch client engagement and enhancement loop
Led the migration of the retail point-of-sale and pharmacy management systems with a $25M project budget and a 7-person team.
Reverse-engineered existing behavior, developed process specifications and worked with the UI team on wireframes.
Used client feedback after release to refine the experience and the supporting requirements.
Preview a contribution below; open the organization above for full work and cases.
EARLIER FOUNDATIONS
Benefits, clinical systems and data.
2013–2016
Cigna Health
Product requirements across formulary, rebate billing, specialty pharmacy, drug lists and pharmacy networks.
Product Owner, Senior Advisor
Explore Cigna Health →
Product Owner, Senior Advisor · 2013–2016
PHARMACY BENEFITS EXPERIENCE
Drug data, manufacturer billing and rebate sharing.
Delivered product
Drug Catalog
Shared drug feeds
Consistent model
Publish for use
I led business-process and requirements sessions, analyzed First Databank and Medi-Span feeds, and worked with an analyst on the data model, user interface and roles. The first milestone used GPI and GCN criteria to retrieve the matching NDCs.
I worked on billing packages and manufacturer invoices, rebate calculations and projections, price-protection calculations, receivables and the reports needed to support the process.
I captured the sharing requirements and related reports within the pharmacy rebate application, alongside the business models for billing, calculations and incoming payments.
Owned product requirements across formulary, rebate billing, specialty-pharmacy, drug-list and pharmacy-network capabilities.
Connected business rules with design specifications, reporting and data-mart needs.
Served as SME for business, design and QA teams through implementation.
Preview a contribution below; open the organization above for full work and cases.
2010–2011
Anthem
Reporting use cases and process flows with physicians for a clinical decision-support initiative.
Senior Business Systems Analyst
Explore Anthem →
Senior Business Systems Analyst · 2010–2011
Payer systems
Key work
Developed reporting use cases, report mockups and process flowswith business stakeholders, including physicians, for a clinical decision-support initiative
Specified login, authentication and authorization behaviorworked with clinical users, information security and legal partners on access requirements and application disclosures
Helped QA develop test cases, prioritized defects and enhancement requestsand contributed use-case and design documentation
Developed reporting use cases, report mockups and process flows with business stakeholders, including physicians, for a clinical decision-support initiative.
Specified login, authentication and authorization behavior; worked with clinical users, information security and legal partners on access requirements and application disclosures.
Helped QA develop test cases, prioritized defects and enhancement requests, and contributed use-case and design documentation.
Preview a contribution below; open the organization above for full work and cases.
2011–2013
Express Scripts
Functional requirements for pharmacy-benefit reporting and a Teradata data warehouse.
Senior Systems Analyst
Explore Express Scripts →
Senior Systems Analyst · 2011–2013
Pharmacy benefits
Key work
Wrote functional requirements for pharmacy-benefit reporting and a Teradata data warehousegathering needs from business owners, end users and subject-matter experts
Documented source-to-target mappings, transformation rules, entity relationships and reporting flowsso developers could connect business definitions with the underlying data
Supported user acceptance and operational-readiness testingclarified requirements through data mappings, reporting flows and stakeholder reviews
Wrote functional requirements for pharmacy-benefit reporting and a Teradata data warehouse, gathering needs from business owners, end users and subject-matter experts.
Documented source-to-target mappings, transformation rules, entity relationships and reporting flows so developers could connect business definitions with the underlying data.
Used SQL in Teradata and Excel queries for reporting; specified report fields, templates, frequency, filters, sorting and grouping.
Supported user acceptance and operational-readiness testing, and clarified requirements through data mappings, reporting flows and stakeholder reviews.
Preview a contribution below; open the organization above for full work and cases.
2009–2011
Blue Cross Blue Shield of Florida
Business and technical requirements across integration, application and reporting work.
Systems Analyst III
Explore Blue Cross Blue Shield of Florida →
Systems Analyst III · 2009–2011
Payer systems
Key work
Gathered business and technical requirements across integration, application and reporting workusing stakeholder interviews and joint requirements sessions
Authored UI use cases and functional specifications with business, engineering and QA teamsused prototypes and process flows to make proposed behavior reviewable
Analyzed requirements and modeled business processesmaintained links between change requests and requirements
Gathered business and technical requirements across integration, application and reporting work, using stakeholder interviews and joint requirements sessions.
Authored UI use cases and functional specifications with business, engineering and QA teams; used prototypes and process flows to make proposed behavior reviewable.
Queried source data with SQL and documented mappings and logical data models to connect business meaning with system behavior.
Analyzed requirements and modeled business processes, maintained links between change requests and requirements, and clarified specifications with developers during delivery.
Preview a contribution below; open the organization above for full work and cases.
Career timeline
Seven employers · 2009–now
Complete timeline · motion is optional
Since 2009, five highlights pinned where they happened.
My approach to product leadership, in 1 minute 45 seconds.
Read the video transcript
Some claims never reached the audit table.
I asked what never reached the report. Over three years: 300,000 claims, about ten million dollars. I put a daily check in place.
I'm Unnat Patel. I lead products from strategy to measured outcome, starting with the question nobody has asked.
Since 2009: payer systems, pharmacy benefits, retail technology, enterprise commerce, pharmacy operations. Seventeen years, from systems analyst to a 14-person product team and an $18M budget.
At Amazon Business I owned Punchout across more than 100 procurement systems and turned its slowing growth around. Amazon reported new adopters up 50 percent in 2023.
In claims work: three million manual claims automated, fifteen minutes saved on each.
At Amazon Pharmacy: reporting to all fifty states and D.C., about 2,250 reports a day, and three generative-AI agents in production.
And I build with AI myself. JobWatch searches open roles, matches each against seventeen years of experience using RAG over a vector index, scores the fit, and tracks applications. The candidate applies selectively, only to the best fits.
I am a pharmacist as well as a product person, so I always ask: what happens to the person on the other side if we get this wrong?
The cases are on the site. Start with the claims.
Built with AI, judged as a pharmacist
JobWatch, which I built, searches roles, matches my work record via RAG + vector index, scores fit and tracks applications: selective, best-fit.
I am a pharmacist as well as a product person, so I ask what happens to the person on the other side if we get this wrong.
Focused work account · Cigna Pharmacy
Delivered product
One drug catalog, many pharmacy workflows
Departments maintained their own drug lists. I helped turn those separate lists into a centralized catalog with shared source data, a consistent model and a workflow for creating and approving lists.
Business and functional requirements; product roadmap and workflow design
My contribution
I led business-process and requirements sessions, analyzed First Databank and Medi-Span feeds, and worked with an analyst on the data model, user interface and roles. The first milestone used GPI and GCN criteria to retrieve the matching NDCs.
What the work delivered
The team delivered a transaction store, a master drug-data model and a librarian interface for creating and approving drug lists for consumers.
01
The fragmented starting point
Individual departments managed and maintained their own drug lists. I worked with pharmacy business groups to capture the current process, define the future process and identify the requirements for a shared drug-list repository.
02
The work I owned
I facilitated business-process modeling and requirements sessions, translated business needs into functional specifications, and reviewed the requirements with business, development and QA. The work included data mapping, GUI use cases, report specifications, API service specifications and calculation rules.
03
A focused first milestone
I shaped a roadmap that began with an MVP: select GPI and GCN criteria and retrieve the available NDCs. With an analyst, I divided the delivery into source-data ingestion, the supporting data model and the user interface with workflow roles.
04
The delivered workflow
The resulting product combined a raw-data transaction store, a master drug-data model and a librarian interface to create and approve lists. The later use of this catalog by another Cigna business was a separate reuse decision, rather than the original catalog launch.
Rebate billing connects drug-level calculations to manufacturer invoices and payments. I defined the requirements and business-process models that made those connections explicit.
Business analysis, process models and requirements
My contribution
I worked on billing packages and manufacturer invoices, rebate calculations and projections, price-protection calculations, receivables and the reports needed to support the process.
What the work delivered
The work translated a connected financial workflow into application requirements and reporting specifications for pharmacy teams.
01
The connected business process
I created business requirements and process models for the pharmacy rebate application. The scope covered manufacturer billing packages and invoices, prescription rebate calculations, projections, payment receivables, sharing and related reports.
02
My contribution
I made the business logic and reporting needs explicit so development and QA could work from agreed requirements. My work included rebate-detail reporting, price-protection calculations, invoices and reporting.
03
Connected to sharing
Rebate sharing is a related part of the same application family. The incoming billing and payment workflow connects to the downstream sharing process and its reports.
Billing is only part of the rebate story. I also worked on the rebate-sharing process and its reports, keeping that downstream work connected to calculations and payment receivables.
Business requirements and process modeling
My contribution
I captured the sharing requirements and related reports within the pharmacy rebate application, alongside the business models for billing, calculations and incoming payments.
What the work delivered
The requirements described both the incoming rebate workflow and the sharing process that followed it.
01
A distinct part of the same application
The Cigna rebate application included sharing processes and related reports alongside billing and receivables. I worked on those connected requirements so the downstream sharing workflow remained visible.
02
What I contributed
I created business requirements and business-process models spanning rebate calculations, manufacturer invoices, receivables, sharing and reporting. I also worked on rebate-detail reports and invoice reporting across the billing and sharing systems.
03
Following the full process
Looking across billing and sharing helped connect the calculation, incoming payment and downstream reporting work. The requirements needed to describe those handoffs in terms that business, development and QA could review together.
The oncology workflow brought patient notes, history and reports together so clinicians could review three treatment options with IBM Watson support.
Business Systems Analyst; reporting, workflows and application requirements
My contribution
I worked on reporting use cases, report mockups and process flows, and helped define the application’s access and security requirements with business, information-security and legal partners.
What the work delivered
My contribution connected clinical users’ needs to reviewable workflows, reporting and application requirements.
01
The clinical workflow
The work supported oncology treatment exploration using patient notes, history and reports. The workflow presented three options for clinical review.
02
My responsibility
As a business systems analyst on WellPoint Care Assistant, I developed reporting use cases, report mockups, process flows and use-case diagrams. I worked directly with business stakeholders, including physicians, through requirements and design reviews.
03
Access and application requirements
I also contributed to application security requirements and worked with information-security and legal partners on access, terms of use and service disclaimers. Requirements, mockups and workflows made the intended behavior reviewable by the teams building and using the application.
Focused work account · Cigna Supplemental Benefits / Evernorth
API reuse
Reuse the drug data already in the business
A sales application needed drug data. I recognized that a prior Cigna Pharmacy catalog already had the source feeds and worked with both teams to reuse its interfaces.
Cross-team product discovery and integration alignment
My contribution
I checked with my former pharmacy team that the catalog and feeds were still in production, established that consumer APIs existed, and brought the catalog and sales-application teams together to assess the integration.
What the work delivered
The sales-application team used the existing API instead of establishing a separate drug-data subscription for the same need.
01
A separate chapter from catalog creation
This decision happened later, during work for Cigna Supplemental Benefits. I had previously worked on the pharmacy catalog and knew there might already be a useful capability inside the company.
02
What I did
I contacted the former team and confirmed that the First Databank and Medi-Span feeds remained in production and that APIs were available to consumers. I arranged the discussion between the sales-application team and catalog team to check whether those APIs met the need.
03
The result
The consuming team agreed to use the existing API. The original catalog could support another business workflow through an established enterprise interface.
Focused work account · Cigna Supplemental Benefits / Evernorth
Launched product
Launch a benefit across the whole member journey
A dental, vision and hearing product needed to work beyond enrollment. I organized the launch across product configuration, member experience and the claims-administration handoff.
Technical product management; roadmap and integration delivery
My contribution
I built the roadmap, converted milestones into epics, defined acceptance criteria and coordinated the product, enrollment, policy, digital, claims, ID-card, EOB and reporting work.
What the work delivered
The product launched for Medicare supplemental customers with the enrollment and claims-administration integration in place.
01
The complete launch
My responsibility was to launch the dental, vision and hearing product for Medicare supplemental customers, including enrollment installation at Cigna and integration with the claims-administration partner.
02
The roadmap I owned
I divided the roadmap into product configuration, enrollment application changes, policy configuration, digital integration, claims management, ID cards and EOBs, and reporting. I turned milestones into epics, set priorities and clear acceptance criteria, and worked with the teams against the launch plan.
03
A second path for enrollment
The enrollment integration also needed a fallback when the partner API was unavailable. I proposed and coordinated a file-based backup with the partner. The enrollment-resilience account explains that decision and its production use.
Focused work account · Cigna Supplemental Benefits / Evernorth
Production fallback
Give enrollment a fallback before it fails
The new benefit used an API to publish enrollment to a claims-administration partner. Testing made me question how that path would behave during an outage, so I proposed a second way to deliver the same enrollment.
Technical product management; partner integration and resilience
My contribution
I worked with the partner on an existing file-processing capability and coordinated SFTP connectivity and enrollment-file generation as a fallback.
What the work delivered
Production support used the backup to publish memberships when the API was unavailable.
01
The risk I noticed
During testing for the new benefit, I saw enough integration issues to question the reliability of a new API spanning two organizations. The customer needed enrollment to reach the claims-administration partner even when that service was unavailable.
02
A practical second path
I discussed fallback options with the partner and learned it already supported traditional file processing. I proposed using that capability during API failure, and the teams set up SFTP connectivity and enrollment-file generation.
03
Used in production
Production support used the fallback during subsequent outages to publish memberships. The second delivery path gave the team a practical way to continue enrollment when the API was unavailable.
Focused work account · Cigna Supplemental Benefits / Evernorth
Launched member self-service
Put the deductible answer in the member’s hands
Members had to call customer service to learn how much of their deductible they had met. I helped put that answer into the digital experience using the same underlying calculation.
Technical product management; accumulator logic and digital delivery
My contribution
I reverse-engineered the Medicare Part A, Part B and Plan K accumulator logic, worked with engineering to reproduce the required behavior, and kept the API tied to the core calculator.
What the work delivered
Members could view their accumulator information through the digital platform instead of relying solely on a service call.
01
The service problem
The existing path required a member to call customer service, where a representative looked up the deductible-met amount in the policy system and explained it. I proposed making that information available directly in the digital platform.
02
The product and technical work
I developed the roadmap and worked through the existing accumulator rules so the new experience would use the same calculation logic. With engineering, I built the application behavior around the core calculator and its API.
03
The delivered experience
The application was deployed to the digital platform, and members used it to track their accumulators. This is a distinct member self-service outcome within the broader digital migration.
Different insurance products had their own enrollment systems and could create duplicate identifiers. I proposed a common identifier service and a way to connect it to the enrollment program.
Customer MDM product management; proof of concept and integration proposal
My contribution
I asked the team to test the approach, identified an existing identifier algorithm we could reuse, and presented the service and integration plan for funding.
What the work delivered
The service was deployed and integrated with enrollment, producing identifiers designed for use across ID cards, IVR, digital and customer service.
01
Why identity mattered
Customer MDM was responsible for maintaining identity while insurance products continued to use separate enrollment platforms. I saw the need for a shared identifier service rather than treating each product’s identifier as an isolated concern.
02
My decision and proposal
I asked the team for a proof of concept, explored reuse of an existing identifier algorithm and prepared the proposed service and integration steps for program leadership.
03
A funded, integrated service
Leadership funded the work, and the service was deployed and connected to enrollment. It supplied IDs usable as card numbers and compatible with IVR, digital and customer-service requirements.
Focused work account · Cigna Supplemental Benefits / Evernorth
Implemented workflow
Move product approval into a usable launch workflow
Product approval did not mean a benefit was ready to sell. Commission structures still moved through manual approvals and loading steps, so I designed a connected workflow for that final stretch of launch.
Technical product management; workflow design and funding case
My contribution
I mapped the process with product, commissions, actuarial and marketing teams, identified approval and loading bottlenecks, and proposed a web workflow with notifications, backup approvers and versioned templates.
What the work delivered
The workflow received funding and was implemented, connecting approved commission structures to the enrollment and policy platform.
01
The gap after approval
The product team designed a commission structure, collected approvals from commissions, actuarial and marketing, and then loaded the product into the enrollment platform. This manual process delayed launch after state approval.
02
The work I led
I scheduled working sessions with the business groups to map the process and pain points. I then designed a web-based workflow, notifications, backup approvals and automated loading of an approved commission structure, with a roadmap that leadership could fund.
03
The implemented change
Leadership funded the proposal. The implementation moved commission structures from spreadsheets into versioned templates and connected the approval process to the enrollment and policy platform. This is distinct from earlier BCBS Florida incentive-compensation work.
Three production agents at a national online pharmacy, one standard of accountability.
AI earns a place when it removes meaningful work or improves a decision enough to justify its cost, uncertainty and operating burden. I own three production generative-AI agents, and I hold each to the same standard: define the evidence, evaluate failures, make corrections possible, keep authority with a person for consequential actions, and record the reason for the final decision.
I defined the AI-assisted to AI-primary strategic theme for annual planning, and it was adopted as a planning pillar. The customer assistant resolves 78% of chats without a human. In healthcare, launch is when you have proven safety at scale, not when the code ships.
Production · Customer assistant agent
A customer assistant that resolves 78% of chats without a person
The customer assistant answered common questions using context and retrieval, with a summary for the representative when the issue needed a person. For this illustrative workflow, ordering requires a separate authorized step.
Outcomes: 78% of chats resolved without a human; 18% of voice contacts fully automated; moving from an intent router to ReAct lifted resolution 18%; hot-path optimization cut median inference calls from two to one for 43% P50 and 67% P90 latency improvement and 40–54% lower token cost.
Workflow explanation
Contact arrives Chat or voice · identity established first
Reason and act ReAct loop · one inference call on the hot path
Live data via tools Prescriptions, orders, insurance, pricing
Bounded actions Illustrative ordering requires separate authorization
Resolve or hand off Summary to a person · acceptance is illustrative policy
Measure Illustrative policy · evaluate resolution and handoff
Production · Clinical copilot
A clinical copilot rebuilt when 15-second latency made it unusable
The copilot supported clinical operators with curated procedures, case summaries and next-best actions. The illustrative validation control checks latency and accuracy before expanding the workflow.
Outcomes: P90 15 s to 1.6 s; a model change to a higher per-token cost model with fewer turns lowered net cost; a storage-key change cut memory cost 95%.
Workflow explanation
Case or call Operator opens a case or takes a call
Retrieve Curated procedures and knowledge with citations
Summarize Issue, history and next best action
Stream Illustrative response delivery · validate latency and accuracy
Operator decides Clinical authority stays with the person
Validate Illustrative policy · check latency and accuracy
Production · Claims and billing agent
A claims and billing agent that explains 800+ rejection codes
The billing workflows are in production after pilot and ramp-up. The agent interprets rejection knowledge and can correct a 30-day supply to the allowed 28 days, update insurance and resubmit, or refile an approved 30-day quantity when a 90-day request exceeds the insurance limit. Clinical/DUR edits go to a pharmacist for manual verification and approval; brand/generic prescription and DAW edits go to a technician. Prior authorization goes to a PA bot for Cover My Meds filing, follow-up after four unresolved days and customer notification after approval. Other paths compare coupon and insurance pricing or communicate the next available refill date. I integrated the billing agent into the Amazon Pharmacy platform after prescription typing and launched the prescription flow: a technician or pharmacist refiles after making the required edit, and the agent suggests further changes. The work affected more than 100,000 prescriptions per month at Amazon Pharmacy.
Workflow explanation
Claim rejects One of 800+ codes · representative asks
Retrieve Rejection-code knowledge base
Look up Authorized billing context and rule limits
Interpret and route Allowed billing actions · clinical edits to pharmacist; prescription edits to technician
Guardrails Illustrative policy · record and review breaches
This illustrative breach-review control records safety exceptions and routes them for review. Candidate prompt, model and guardrail changes are evaluated before reuse. Action permissions remain specific to the authorized workflow.
Volume pricing becomes an orderable commitment after the quote is won.
Requestvolume pricing
Win firstthen lock + reserve
After orderreconciliation / invoice
→→
After the quote is won ↓
→→
Commercial workflow. Local eligibility and unit conversion examples are illustrative, not measured results. Select a labeled step for an overview and process details.
Read the complete process
Quote request
Enterprise buyers request quotes from Amazon Business and third-party providers inside their sourcing platform. The response path makes product match, available inventory and the requested unit explicit.
Process note: The request form is simplified. It contains no buyer identifier, historical conversion rate or recorded quote.
Volume pricing
Catalog match and availability inform a suitable response. A pack price and an each price cannot be compared without conversion factors. Illustrative arithmetic: $4.25 × 12 ÷ 6 = $8.50 per case of 12.
Process note: Illustrative eligibility: more than 1,000 units OR more than $10,000. Exactly 1,000 units and $10,000 does not meet either strict threshold. The existing local calculator remains the place to try inputs.
Quote won
After a quote is won, the workflow locks price and reserves inventory while the customer orders. This is the commercial transition between quote response and the order path.
Process note: No win rate, completed pilot, lock duration or reservation duration is asserted.
Lock price + reserve
Price lock and inventory reservation follow quote win and support the customer while they order. The two objects in the illustration are parallel commitments in this same state.
Process note: The lock and stock specimens show function. They do not imply a specific time limit or inventory quantity.
Submit the order
The customer submits the order through Ordering API/XML. This order-submission role follows the won quote and its price lock and inventory reservation.
Process note: The XML page is a conceptual artifact; it is not an actual API schema or customer payload.
Post-order follow-through
Reconciliation/Invoice API supports the post-order workflow. Its role is distinct from Ordering API/XML, which handles the submission of the order.
Process note: The invoice specimen is illustrative. No invoice amount, fulfillment rate or reconciliation outcome is added.
2022–now
