Every sample document, tool, definition and long-form account in one place. Documents, Toolkit and Writing are the three groups; search reaches individual sections.
The supporting material
Library
A closer look at the work.
Documents that explain a decision. Methods that make it repeatable. Longer accounts of what I built and learned.
Historical investigation · daily control implemented
Daily claims reconciliation
A processed-claims report could miss claims that never reached it.
My contribution. I extended a testing observation into a three-year, 20-million-claim investigation and put a daily received-versus-processed audit in place.
300,000 claimsfound unprocessed · about $10M in claim value
Turn a supported paper claim into a processable transaction while keeping its original image retrievable.
Where used
Cigna Supplemental Benefits · paper claim conversion.
My contribution
Collaboration with an external company on OCR and custom rules for CMS-1500 and UB-04 forms.
Stage & outcome
Implemented conversion: 15 minutes saved per paper claim; about 300,000 paper claims per month; 2% of manual claims avoided.
Two outputs with different purposes
Input or output
What it supports
CMS-1500 → 837P
Professional claim processing.
UB-04 → 837I
Institutional claim processing.
Image + index → OnBase
Retrieval for appeals and re-review, linked by a common claim ID.
The electronic claim goes to the claims processor for adjudication, followed by payment, invoice and EOB outputs. The generated EOB is distinct from the primary-payer EOB that arrives with a paper claim.
Provider resolution, daily reconciliation and the claims-engine replacement are separate projects.
Make the allowed next step explicit, including the exception.
Purpose & audience
A shared contract for product, engineering, QA and claim operations.
Where used
A reconstructed intake example informed by the separate paper-conversion and provider-resolution projects.
Decision supported
Whether the evidence is sufficient for a claim to advance to the next state.
Reconstructed requirements · proposed controls · not a historical production specification.
Three requirements from the sample
Capability
Expected behavior
FR1 · Supported forms
Select the professional or institutional mapping for a complete CMS-1500 or UB-04. Quarantine unsupported or unreadable forms.
FR2 · Extraction & correction
Show the source beside an uncertain field. Record the authorized correction and revalidate before advancing.
FR5 · EDI validation
Validate the applicable 837P or 837I against its implementation and receiver contract. Block invalid transactions with an actionable field-level reason.
Why the state matters
The provider API supplies a resolution result. The receiving claims system retains adjudication authority. Submission, acknowledgement and final disposition remain separate states.
The full sample contains ten requirements, provider response semantics, data boundaries and recovery behavior. Its migration replay requirement belongs to the separate platform example.
Choose an automation path whose exceptions remain visible.
Purpose & audience
Make the tradeoff reviewable by product, engineering, operations and decision makers.
Where used
A reconstructed intake decision, informed by my healthcare product experience.
Decision supported
Which option removes repetitive work while keeping uncertainty and recovery accountable.
Sample decision record · this comparison is not a historical procurement or approval record.
Option
Tradeoff in the sample
Manual optimization
Less disruption, but repetitive entry remains. Fallback baseline.
OCR + validated transaction + review
Eligible automation with inspectable exceptions. Selected sample path.
Unrestricted straight-through processing
Unresolved identity and quality risk. Rejected in the sample.
Reversibility changes the evidence
An exception label is easier to reverse than a provider identity rule or a platform cutover. The sample treats platform retirement as a separate commitment, with its own continuity and recovery evidence.
Can an operator complete and recover a claim without bypassing evidence?
Purpose & audience
A task-based walkthrough for claim operations, provider-data stewards, customer care and QA.
Where used
A reconstructed medical-claims intake example, connected to the Paper-to-EDI account.
Decision supported
Whether intended users can interpret states and exceptions well enough to accept a release.
Status: NOT RUN. No execution results or historical sign-off are asserted.
Scenario
Expected result
Status
Valid supported form
Correct 837 variant; acknowledgement distinguished from final disposition.
NOT RUN
Uncertain required field
Correction lineage retained; revalidation before advancement.
NOT RUN
Invalid EDI or delayed acknowledgement
Correct error action; no unsupported completion promise.
NOT RUN
The complete protocol includes prerequisites, eight scenarios, execution records, defects, retest and acceptance. Expected behavior is the starting point for evidence collection, not proof that acceptance occurred.
Some received claim files never reached the processing audit table.
My contribution
I extended a testing observation through a sample and then a three-year, 20-million-claim, 50 GB analysis. I put a daily received-versus-processed audit in place.
Stage & outcome
The investigation found 300,000 missing claims worth about $10M. The business processed them, and the continuing daily control made fallout visible.
The implemented control
Capture received-file metadata. The audit table records file name, unique source-file ID, claim count and claim ICNs.
Keep the source-file ID on adjudicated claims. This connects the received inventory with processed records.
Compare received and processed each day. Tableau surfaces fallout for investigation and the report joins the weekly leadership readout.
The approximately $10M is the value of claims found unprocessed, not savings. The 300,000 claims are a historical finding across the expanded investigation, not a monthly rate.
Connect a finding to recovery and an ongoing control.
Purpose & audience
A concise account for operations and leadership of the issue, its impact and the control that follows.
Where used
The separate Cigna Supplemental Benefits missing-claims investigation.
Decision supported
How to expose unresolved work and keep it from being counted as complete.
Reconstructed document format. The investigation and delivered daily control are described in the linked historical case.
Issue → action → continuing check
Issue. Testing EDI 837 files revealed a mismatch between claims received and claims processed. A sample traced the gap to inbound files.
Action. The expanded analysis covered 20 million claims and identified 300,000 unprocessed claims worth about $10M. The business processed them.
Continuing check. An audit table and retained source-file ID support a daily reconciliation, Tableau fallout visibility and the weekly leadership readout.
The operating lesson is to measure completeness from the received population; a success-only report cannot reveal work that never reached it.
Read the document in the context of the decision it supports.
These samples draw on separate paper-conversion, provider-resolution and integration experiences. The missing-claims operating record connects to daily reconciliation. Requirements, thresholds and review records are illustrative, not employer documents or historical sign-offs.
For general artifact structure beyond these healthcare examples, read the 34 document format guides.
Find the method, then inspect the contribution.
Purpose
Understand the tools and methods named in the work.
Where used
Data work, delivery, product practice, healthcare, commerce and AI accounts.
Decision supported
Whether an entry describes personal work, delivery context or recorded familiarity.
Data mapping & migration specifications
I write source-to-target mappings with transformations, defaults and rejection behavior. Sample records make the agreement concrete for engineers and testers.
Explore 16 chapters on the projects, technical decisions and lessons behind my work.
The white paper develops the perspective on risk, evidence, people and release decisions.
Find the constraint before changing the response.
Problem
Basket-level quoting was not converting as intended.
My contribution
I used five months of funnel data to separate eligibility and unit-of-measure problems, then wrote a technical strategy around a marketplace offer, price lock and automation of manual steps.
Stage
Technical strategy and delivery sequence for Integrated Quoting.
What the reading helps you inspect
Product eligibility and pack-versus-each interpretation are different constraints. The account follows how analysis changed the proposed response path.
The workflow distinguishes a quote response, a won quote, price lock and inventory reservation, order submission, and post-order reconciliation. Local examples explain the mechanics; they do not establish achieved conversion or pilot outcomes.
Use AI where it removes meaningful work and keeps consequential decisions accountable.
Where used
Amazon Pharmacy · customer assistant, clinical copilot, claims and billing.
My contribution
Product ownership of three production generative-AI agents and the AI-assisted to AI-primary planning theme.
Decision supported
How capability, evaluation, correction and human authority fit together.
Read each account in its own scope
Customer assistant. The account reports 78% of chats resolved without a human.
Clinical copilot. The account describes a rebuild that reduced P90 latency from 15 seconds to 1.6 seconds.
Claims and billing. A distinct production account with its own workflow and evidence.
JobWatch is my personal product. Agentic customer care is a separate design study, not an attributed employer launch.
Explore the document journey
See the decision inside the document.
Seven stages. Readable previews. Open the supporting documents when you need the detail.
Portfolio samples from my healthcare product experience. Requirements, thresholds and review records are illustrative; they are not employer documents or historical sign-offs.
Discover · 2 documents
Find the problem before choosing the system.
Document quality
Readable source. Verified fields.
Paper claim conversion
Provider identity
Trustworthy evidence. Explicit match state.
Provider resolution
→
Transaction continuity
Receiver state. Recovery ownership.
Platform replacement
Separate projects; their outcomes are not combined.
Three product problems. Separate evidence.Read 2 supporting documents
Before a launch or a channel turnaround. Read by sales, services, marketing and partner leaders.
From the record
An integration-channel go-to-market strategy connecting sales, services, self-service, marketing and partners with adoption.
11 · What we are building, what we are not, and how we will know — versioned and capped
Inside it
Problem, users, scope and non-goals.
Success criteria with target values; the defect metric paired with every automation.
Functional requirements by workflow; exception handling written out, not "TBD".
Risk register; open questions with owners; version history.
When · who
Numbered versions through review; signed by each partner team. Capped — a forced pilot decision after too many rounds.
From the record
Safety-service requirements; review-context requirements aligned with specialist partners; billing and hosted-catalog requirements refined through analysis.
12 · Start at the hard date and walk backwards until you reach today
Inside it
The immovable date and what makes it immovable.
Milestones backwards from it, each with an owner and an exit criterion.
Dependencies and the slack — or the lack of it — on each.
When · who
Any regulatory deadline or platform deprecation. Read weekly in the business review.
From the record
A pharmacy launch planned backward from a compliance obligation, with readiness evidence and a bounded introduction.
A customer-care transition plan connecting migration and future capability.
13 · Every screen, rule and message, precisely enough to build and test from
Inside it
Functional behaviour by screen or service: inputs, validations, outputs, messages.
Business rules as tables; state transitions as diagrams.
Error and exception handling per rule.
Traceability to the BRD requirement each function satisfies.
When · who
Design phase; owned with the analyst and engineering lead. Read by engineers and testers.
From the record
A specification converting paper claims to electronic 837 format.
Verification-workflow specifications with explicit acceptance conditions.
14 · The technical design — with the product manager writing the problem, constraints and alternatives
Inside it
Problem statement and constraints — the product manager's section.
Alternatives considered, with the tradeoff that decided it.
Architecture, data flow, interfaces; non-functional requirements.
Rollout and rollback approach; monitoring.
When · who
Before build; reviewed with senior engineers. The product manager signs the constraints and the alternatives.
From the record
Synchronous versus asynchronous behavior evaluated against the professional’s responsiveness needs.
A quoting response approach chosen against more extensive alternatives, with a follow-on design documented.
15 · Source field, target field, transformation, default, reject — for every attribute
Inside it
Field-by-field mapping with data types, formats and required flags.
Transformation logic and lookup tables; defaults when the source is empty.
Reject rules and where rejects go.
Sample records for the test set.
When · who
Any migration or integration. Read by engineers, testers and the receiving system's owners.
From the record
Enrollment, claims and policy data mapped for a shared-platform migration.
Administrative records normalized to a structured representation for bounded assistance.
16 · What the caller sends, what comes back, and what happens when it doesn't
Inside it
REST/JSON request and response schemas; event schemas for streaming; file layouts for EDI, cXML, SFTP.
Error codes and retry semantics; idempotency keys.
Latency and availability expectations.
When · who
Design; agreed with partner and platform teams before build.
From the record
Verification interfaces with defined responsibilities.
Model Context Protocol tool contracts with bounded, documented actions.
Pricing and quoting APIs for procurement integration.
17 · Given, when, then — the test written before the story
Inside it
Given a precondition, when an action, then an observable result — for the happy path and every exception.
Data conditions and boundary values.
When · who
Before a story enters a sprint. Read by engineers and testers; the operator's language, not the system's.
From the record
Acceptance criteria used across scrum teams in the operator’s language.
18 · The work, broken down so it can be prioritised, estimated and demoed
Inside it
Epics tied to a business outcome and a metric; features under them; stories under features.
Story format: who, what, why; acceptance criteria attached.
Dependencies and enabler work called out, not hidden.
When · who
Continuously, in Jira or Jira Align. Read by the teams, the release train and leadership dashboards.
From the record
A digital migration divided into epics representing member-facing capabilities and their dependencies.
19 · Cost of delay divided by job size — so the argument is about the inputs, not the ranking
Inside it
For each epic: user/business value, time criticality, risk reduction or opportunity enablement — relative scores.
Job size in the same relative scale.
Weighted shortest job first = cost of delay ÷ size; the ranked list falls out.
When · who
Before each program increment. Read by product management and business owners together.
From the record
Portfolio prioritization across teams, with enablers and business-value features balanced explicitly.
Risk-based prioritization applied to safety work.
20 · Ten to twelve weeks of committed objectives across every team on the release train
Inside it
Team objectives for the increment, with business value scored by the business owners.
The program board: features by sprint, dependencies drawn as strings between teams.
Program increment planning, quarterly, two days, everyone in the room. Read for the whole increment.
From the record
Release-train planning linking multiple teams, portfolios and a funding cycle.
21 · Two weeks of work made visible — and the flow of work that doesn't fit in sprints
Inside it
Sprint goal; stories pulled against capacity; acceptance criteria present on every one.
Kanban for operational and support flow: columns as states, work-in-progress limits, aging visible.
Demo notes and the decision log.
When · who
Every sprint; the board every day. Read by the team; the demo by stakeholders.
From the record
Jira and Jira Align across the release train; Kanban for compliance and on-call work where arrival, not planning, sets the pace.
22 · Fixed cadence, variable scope — the train leaves on time
Inside it
Increment boundaries, sprint boundaries, system demos, planning days.
Release windows and freeze periods; the compliance dates that cannot move.
Feature flags that decouple deployment from release.
When · who
Set per year; referenced by every team and by operations.
From the record
Enrollment work planned against a fixed business date, with continuity and fallback considered.
23 · Every requirement has a test; every test has a result
Inside it
Scope by test type: unit, integration, automated regression, performance, UAT, security.
Traceability: requirement → test case → result.
Test data strategy — generated, masked, production-shaped.
Entry and exit criteria; blocked tests with disposition.
When · who
Drafted in design; executed in test; read at go/no-go.
From the record
Functional tests for a launch, with environment limitations recorded and owned.
Masked production-shaped claims used to make representative regression data practical.
24 · The operator's scenarios, run by operators, signed by operators
Inside it
Scenarios written in the operator's language — the missing allergy, the rejected file, the customer with two accounts.
Free-exploration time built in; defects logged with severity.
Sign-off with names and dates.
When · who
After integration testing, before go/no-go. Pharmacists, claims processors, sales advisors.
From the record
Pharmacist UAT for every clinical workflow change; enterprise customer pilots for integration products.
25 · The new engine against the old, field by field, on thousands of real inputs
Inside it
Population replayed; fields compared; parity rate against the threshold.
Disagreement classes with a disposition for each — new engine right, defect fixed, accepted difference.
Performance under replay load.
When · who
Before cutover of any safety or financial engine. The evidence at go/no-go.
From the record
Historical comparison and classification of disagreements before changing a safety-related engine.
26 · One approval from each function — written down, with what they saw
Inside it
The evidence reviewed: parity, performance, UAT, security.
Named approvers from safety, compliance, legal and operations; the conditions attached.
Rollback plan and who can call it.
When · who
The day before the pilot. Signed by each function's lead.
From the record
Cross-functional readiness review for a pharmacy rollout, including explicit scope exclusions.
27 · Pilot → staged expansion, with what we watch and when we stop
Inside it
Pilot cohort, site, shift and duration.
Step percentages, the metrics held at each step, and the thresholds that stop a step.
Named risks with mitigations; day-one production validations.
When · who
Written with operations before go/no-go; executed by product with live tracking.
From the record
A verification platform introduced in bounded stages; a pharmacy review capability planned against a fixed obligation.
28 · The movement, reported against the criteria set before building
Inside it
What launched, for whom, and why it matters.
Each success criterion from the BRD with its before/after value.
What is next; who to thank.
When · who
At 100% dial-up. Read by leadership and every partner team.
From the record
Announcements for the safety-service rebuild and the state-reporting automation — latency, automated-success and manual-review movement against pre-set targets.
29 · The operator can use it, and the floor knows what to do when it fails
Inside it
Prototype-based walk-through of every scenario, delivered through the learning management system for tracking.
Standard operating procedures and one-page job aids.
Floor-support plan for day one; escalation paths.
When · who
Ships with the launch, not after. Operations training leads and product together.
From the record
Prototype-based training for a launch; operating guidance; product enablement across regions.
30 · Onboarding is a product with a cycle time — measure it, then shorten it
Inside it
Self-service steps a customer's own team can complete.
Configuration checklists per platform; test transactions; go-live criteria.
A shared launch-readiness definition so services and sales agree on done.
When · who
Any integration product. Read by customers, partners and professional services.
From the record
Integration onboarding improved through clearer self-service guidance and a shared readiness definition.
31 · Input metrics, output metrics, defect metrics — the same page every week, so the trend is the story
Inside it
The metrics deck: inputs we control, outputs we get, defects we created — each with trend and target.
Variance commentary only where the line moved; actions with owners and dates.
Quarterly: goals status, roadmap changes, asks of leadership.
When · who
Weekly with the channel; monthly with partners; quarterly with executive stakeholders across regions.
From the record
Channel insights, partner reviews and portfolio-level reporting across regions.
32 · The portfolio on one page: outcomes, lowlights, next decisions
Inside it
Highlights with the number moved; lowlights with the cause and the fix.
Decisions needed from leadership, stated as options.
Portfolio health: on track, at risk, blocked — and why.
When · who
Monthly; created and owned by me. Read from director to vice-president.
From the record
A product review bringing portfolio outcomes, lowlights and next decisions together for leadership.
33 · Root cause, the mechanism that prevents recurrence, the metric that would have caught it
Inside it
Timeline of the incident; customer and business impact quantified.
Five whys to root cause — a mechanism failure, not a person.
Actions with owners and dates; the monitoring gap closed.
When · who
After every significant incident. Read by leadership; the actions tracked to closure.
From the record
A failed assistant-to-human transition led to better handoff visibility and recovery.
A renewal-related defect was investigated, corrected and given clearer monitoring.
34 · Outcome, defect and cost per unit on one screen — or the launch is not done
Inside it
Input, output and defect metrics side by side; alarms on the seams between systems.
Reconciliation views: received vs processed; source vs configured vs reporting.
Drill-down to the record when a number moves.
When · who
Live from day one of the dial-up. Read by operations daily and leadership weekly.
From the record
Claims reconciliation made completeness visible; exception reporting and operator-throughput tracking supported launch review.
Cigna Supplemental Benefits