Healthcare · Enterprise commerce
From pharmacy workflows to the systems businesses buy through.
Trained as a pharmacist.
17 years across payer, PBM, retail and enterprise platforms.Austin, Texas
Integrated Quoting
I found problems in eligibility rules and how pack prices were interpreted, then shaped the response strategy.
Claims intake and reconciliation
I traced missing claims through the intake process and put a daily reconciliation check in place.
Launch sequencing and workflow design
I started with prescription-status questions, opening the new workflow from the existing care tool.
SELECTED ORGANIZATIONS · PRODUCT WORK
Start with the organization. Explore the teams, product decisions and work behind it.
2022–nowAmazon 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
The strategy brought five levers together around one adoption target everyone could see.
Punch out, shop, return.
Cart handoff: the cart returns to procurement for approval and a purchase order.
more than100e-procurement systems
I owned Punchout across them.
Too few connected users were buying.
Activationand time to first order
I addressed adoption and onboarding.
Five levers, each measured.
5 levers into 1 targetfive levers, one adoption target
I wrote the go-to-market strategy across five levers.
A weekly business review tracked it.
One targeteveryone could see
I ran the weekly Punchout insights mechanism.
Is the customer a buyer?
First useful orderat the center of the launch discussion
I learned a partner’s readiness is not a customer’s adoption.
Separate Punch-in lesson: partner readiness was green, but customer adoption was well below goal.
Shifted to demand-side levers
Recovery actions: incentives, pilots, partner lead lists and funds tied to adoption targets for Punch-in.
What I learned
Punch-in: partner readiness green; adoption well below goal.
Punch-in: incentives, pilots, partner lead lists and funds tied to adoption targets.
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
Volume pricing becomes an orderable commitment after the quote is won.
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.
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.
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.
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.
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.
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.
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.
Explore the request, the response, and where a person takes over.
Illustrative ordering requires separate authorization
Task
Tools and action boundary
Resolution and handoff
Operating controls
Workstream · illustrative controls · Routine question
The customer assistant answered common questions using context and retrieval, with a summary for the representative when the issue needed a person.
Explanatory condition and selected responsibilities reconstructed from the source boundaries; not an additional observed event, tool execution or measured result.
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.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
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.
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.
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.
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.
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.
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.
Explore the request, the response, and where a person takes over.
Clinical authority stays with the person
Case support
Human authority
Validation control
Workstream · illustrative controls · Cited support
The copilot supported clinical operators with curated procedures, case summaries and next-best actions.
Explanatory condition and selected responsibilities reconstructed from the source boundaries; not an additional observed event, tool execution or measured result.
Explore the request, the response, and where a person takes over.
Feedback returns to evaluation. Proposed policy: check response quality alongside speed.
Illustrative controls; not production telemetry or measured outcomes.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
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.
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.
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.
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.
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.
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.
Explore the request, the response, and where a person takes over.
Allowed billing actions · clinical edits to pharmacist; prescription edits to technician
Amazon Pharmacy · production after pilot and ramp-up
Billing support after prescription typing, with edits routed to the right person.
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.
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.
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.
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.
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 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.
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.
Claim support
Workflow-specific permissions
Operating controls
Production billing workstream · Explain rejection
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.
Explanatory condition and selected responsibilities reconstructed from the source boundaries; not an additional observed event, tool execution or measured result.
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.
Explore the request, the response, and where a person takes over.
Explore the request, the response, and where a person takes over.
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.
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.
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.
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.
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.
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.
Key work
Key work
Select a contribution to open the organization’s full work and cases.
2018–202214-person team, $18M budget, 15 products across 4 portfolios; 300,000 missing claims and about $10M found.
Senior Manager, Transaction Data Platform
Find the gap between received and processed.
missing claims identified
in unprocessed claim value
Historical reconciliation finding · expanded 20-million-claim analysis
Select a process step for a short overview, then open its details. The comparison is illustrative; the historical totals above describe the investigation.
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.
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.
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.
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.
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.
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.
Key work
Select a contribution to open the organization’s full work and cases.
2016–2018$25M point-of-sale and pharmacy-management migration, 7-person team.
Manager, Business Systems Analysis
Key work
Select a contribution to open the organization’s full work and cases.
EARLIER FOUNDATIONS
2013–2016Product requirements across formulary, rebate billing, specialty pharmacy, drug lists and pharmacy networks.
Product Owner, Senior Advisor
PHARMACY BENEFITS EXPERIENCE
Delivered product
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.
Read Drug CatalogWorkflow requirements
I worked on billing packages and manufacturer invoices, rebate calculations and projections, price-protection calculations, receivables and the reports needed to support the process.
Read Rebate billingWorkflow requirements
I captured the sharing requirements and related reports within the pharmacy rebate application, alongside the business models for billing, calculations and incoming payments.
Read Rebate sharingKey work
Select a contribution to open the organization’s full work and cases.
2010–2011Reporting use cases and process flows with physicians for a clinical decision-support initiative.
Senior Business Systems Analyst
Key work
Select a contribution to open the organization’s full work and cases.
2011–2013Functional requirements for pharmacy-benefit reporting and a Teradata data warehouse.
Senior Systems Analyst
Key work
Select a contribution to open the organization’s full work and cases.
2009–2011Business and technical requirements across integration, application and reporting work.
Systems Analyst III
Key work
Select a contribution to open the organization’s full work and cases.
Seven employers · 2009–now
Since 2009, five highlights pinned where they happened.
A 17-year career, with five examples of the work.
HOW I BUILD
I frame the problem, choose among alternatives, and align the people and evidence needed to deliver. The work continues after launch.
Explore my practice ↗Clinical and billing checks may run in parallel. Controlled-substance checks and reporting are conditional branches, not a universal extra step.
Read the original prescription map
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.
Hosted catalog, PunchOut and quote requests are alternative entry paths. They converge at approval and ordering; every purchase does not require a quote.
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.
Focused work account · Cigna Pharmacy
Delivered product
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
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.
The team delivered a transaction store, a master drug-data model and a librarian interface for creating and approving drug lists for consumers.
01
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
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
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 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.
Focused work account · Cigna Pharmacy
Workflow requirements
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
I worked on billing packages and manufacturer invoices, rebate calculations and projections, price-protection calculations, receivables and the reports needed to support the process.
The work translated a connected financial workflow into application requirements and reporting specifications for pharmacy teams.
01
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
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
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.
Focused work account · Cigna Pharmacy
Workflow requirements
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
I captured the sharing requirements and related reports within the pharmacy rebate application, alongside the business models for billing, calculations and incoming payments.
The requirements described both the incoming rebate workflow and the sharing process that followed it.
01
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
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
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.
Focused work account · WellPoint / Anthem
Clinical decision-support workflow
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
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.
My contribution connected clinical users’ needs to reviewable workflows, reporting and application requirements.
01
The work supported oncology treatment exploration using patient notes, history and reports. The workflow presented three options for clinical review.
02
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
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
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
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.
The sales-application team used the existing API instead of establishing a separate drug-data subscription for the same need.
01
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
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 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
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
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.
The product launched for Medicare supplemental customers with the enrollment and claims-administration integration in place.
01
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
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
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
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
I worked with the partner on an existing file-processing capability and coordinated SFTP connectivity and enrollment-file generation as a fallback.
Production support used the backup to publish memberships when the API was unavailable.
01
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
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
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
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
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.
Members could view their accumulator information through the digital platform instead of relying solely on a service call.
01
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
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 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.
Focused work account · Cigna / Evernorth
Deployed identity service
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
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.
The service was deployed and integrated with enrollment, producing identifiers designed for use across ID cards, IVR, digital and customer service.
01
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
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
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
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
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.
The workflow received funding and was implemented, connecting approved commission structures to the enrollment and policy platform.
01
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
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
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.
Production account · Amazon Pharmacy
Three production agent workflows
I own three production generative-AI agents across customer assistance, clinical support, and claims and billing.
Senior Product Manager – Technical · Amazon Pharmacy
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
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.
Production · Clinical copilot
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%.
Production · Claims and billing agent
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.
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.
Amazon Business · Integrated Quoting
Volume pricing becomes an orderable commitment after the quote is won.
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.
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.
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.
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.
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.
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.
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.