The work across the whole journey.

• Prescription channels and intake quality
• Data extraction with quality evaluation
• Professional review supported by relevant information
• Verification responsibilities and applicable obligations
• Billing response and exception handling
• Fulfillment and relevant review context
• Customer support and human continuity
• Reporting obligations and completeness

Generalized industry reference.

Stage 1 · Intake

Prescription channels and intake quality

What happens

• Electronic prescriptions can use NCPDP SCRIPT; images and transfers require their own interpretation. Channel differences affect data quality and traceability.

What I built or changed

• I investigated a renewal-related defect that created unnecessary work and contributed intake requirements for a customer migration.

Illustrative measures

• Volume by channel; renewal success rate; time in queue; intake defects per thousand.

Stage 2 · Prescription processing

Data extraction with quality evaluation

What happens

• OCR and machine learning can extract information from images; standard identifiers help represent it consistently. Extracted information still needs appropriate evaluation.

What I built or changed

• I worked on prescription data-entry assistance, pairing automation coverage with quality evaluation and operator feedback.

Illustrative measures

• Net automation rate paired with downstream error rate; time to typed; feedback tickets closed.

Stage 3 · Clinical verification

Professional review supported by relevant information

What happens

• A qualified pharmacist reviews relevant information, supported by drug-data checks appropriate to the task.

What I built or changed

• I helped modernize a pharmacist verification experience and its supporting checks. Historical comparisons, responsiveness and professional effort informed readiness.
• I treated alert fatigue as a cause-analysis problem rather than broad suppression; this optimization program is work in progress.

Illustrative measures

• Transactions per hour per pharmacist; automated-success rate; manual-review rate; alerts per prescription; latency p50/p90.

Stage 4 · Controlled-substance & red-flag checks

Verification responsibilities and applicable obligations

What happens

• Controlled-substance requirements and professional verification involve applicable rules and specialist interpretation. A product must make responsibility and uncertainty clear.

What I built or changed

• I developed requirements for verification capabilities and worked with specialist partners to interpret applicable obligations.
• I scoped bounded self-service improvements so professionals could complete appropriate work without unnecessary engineering dependency.

Illustrative measures

• Manual checks avoided; false-positive rate on flags; time to clear; risk score by failure mode.

Stage 5 · Billing & adjudication

Billing response and exception handling

What happens

• Claims exchange uses industry standards. Rejections require understanding the reason and the appropriate next action; a proposed correction is not proof of a successful outcome.

Production support and requirements work

• Billing support is in production after a pilot and phased rollout. Correction controls depend on the workflow.
• I used actuals to refine the projected savings opportunity and written requirements to explain the exceptions.

Illustrative measures

• Paid-on-first-pass rate; billing tasks per month; cost to fill per unit.

Stage 6 · Fulfillment

Fulfillment and relevant review context

What happens

• Preparation, packaging and delivery connect physical activity with information about the intended product. Changes in relevant context can require qualified review.

What I built or changed

• I analyzed differences between earlier review context and later activity, then aligned requirements with clinical and operational partners.
• I worked on clear handling of unresolved conditions and the experience of the customer affected.

Illustrative measures

• Reviews completed; cancellation rate; promise-time attainment; orders saved.

Stage 7 · Patient care

Customer support and human continuity

What happens

• Customers ask about refills, delivery, coverage and other needs through multiple channels. Clinical questions require appropriate professional authority.

What I built or changed

• I shaped customer-care assistance around useful context, checkable suggestions and responsible human involvement.
• I examined continuity when a conversation moved between automated assistance and a representative.

Illustrative measures

• Resolution without a human; handle time; contacts per hundred units; copilot latency and cost per interaction.

Stage 8 · Compliance reporting

Reporting obligations and completeness

What happens

• Reporting requirements vary by jurisdiction. Product work connects applicable obligations with complete information, traceability and responsible ownership.

What I built or changed

• I worked on reporting automation.
• I helped define state-specific reporting rules and failure handling.

Illustrative measures

• Illustrative target: zero missed submissions. Example measure: daily facility reconciliation across source, configuration and reporting.

1. Enrollment activates membership and downstream member access
2. One person, one identifier, across every system that will ever ask
3. Products, plans and the people paid to sell them
4. Paper becomes data, or it becomes a backlog
5. Eligibility, benefits, formulary, rebates — the rules that decide what is paid
6. If a system cannot tell you what it dropped, assume it dropped something
7. The card, the explanation of benefits, the deductible — on a screen, on time
8. The reports the business actually reads — and the test data nobody had

Generalized industry reference.

Stage 1 · Enrollment

Enrollment activates membership and downstream member access

What happens

• Group and individual enrollments arrive as EDI 834 transactions or through sales systems during open enrollment; brokers and agents are paid on what they sell.

What I built or changed

• I modernized enrollment using Kafka, connecting platform behavior with usable member access.
• I worked on a benefits-product launch and made continuity a readiness concern.
• I investigated sales-to-enrollment data quality so campaign reporting reflected the underlying journey.

Illustrative measures

• Time to active member; enrollment fallout; campaign conversion.

Stage 2 · Member identity

One person, one identifier, across every system that will ever ask

What happens

• Customer master data management resolves a person across enrollment, claims, digital and service — the individual and household books of record every other system validates against.

What I built or changed

• I led shared-data product work using Reltio.
• I challenged migration sequencing with dependency evidence and helped protect dependent capabilities.

Illustrative measures

• Match rate; duplicate rate; downstream validation latency.

Stage 3 · Policy administration

Products, plans and the people paid to sell them

What happens

• The policy administration platform holds products, plans and policies; agent and broker incentive programs are configured and paid against it.

What I built or changed

• I automated parts of product setup and approval work, connecting requirements with business-impact analysis and partner readiness.
• I worked on integration between sales and enrollment to reduce avoidable customer waiting.

Illustrative measures

• Launch cycle time; manual entry defects; partner satisfaction score.

Stage 4 · Claims intake

Paper becomes data, or it becomes a backlog

What happens

• Provider claims arrive electronically as 837 professional and institutional transactions, or on paper; paper must be captured, read and converted.

What I built or changed

• I worked on paper-claim to EDI 837 conversion, specifying how paper claims become structured, testable information.
• I helped replace limited parsing capability with more complete handling of claim attributes.

Illustrative measures

• Auto-conversion rate; intake cycle time; attributes captured per claim.

Stage 5 · Adjudication

Eligibility, benefits, formulary, rebates — the rules that decide what is paid

What happens

• Eligibility (270/271), benefits and accumulators; for pharmacy claims, formulary position and the rebate contracts behind it; provider matching.

What I built or changed

• I rebuilt formulary-related workflows, worked on rebate and drug-list capabilities, and served as a specialty-pharmacy SME across business, design and QA.
• I centralized drug information using First Databank and Medi-Span and supported reuse through an API.
• I used a provider-matching proof of concept to inform funding and explain the consequences of changing a match rule.

Illustrative measures

• Auto-adjudication rate; rebate accuracy; fallout per thousand claims.

Stage 6 · Payment & reconciliation

If a system cannot tell you what it dropped, assume it dropped something

What happens

• Payment, coordination of benefits with secondary payers, and the reconciliation that proves every received claim was processed.

What I built or changed

• I identified claims missing from completion reporting and helped establish ongoing completeness visibility.
• I connected more complete claim interpretation with accurate application of payment rules.

Illustrative measures

• Received vs processed, daily; days-to-pay; excess-payment recoveries.

Stage 7 · Member digital experience

The card, the explanation of benefits, the deductible — on a screen, on time

What happens

• ID cards, explanations of benefits, benefits and accumulators surfaced to members in a digital experience.

What I built or changed

• I led work on a member digital migration across enrollment, claims, cards, benefits and accumulators.
• I reverse-engineered Medicare deductible logic for an accumulator experience and examined related service needs.

Illustrative measures

• Digital adoption; call deflection; time from event to display.

Stage 8 · Reporting & analytics

The reports the business actually reads — and the test data nobody had

What happens

• Data marts, operational reports and dashboards over relational databases; regulatory reporting to CMS.

What I built or changed

• I automated claims test-data generation with a script approved by the data-quality team.
• I automated reporting and used Tableau to make reconciliation and exceptions visible.

Illustrative measures

• Report latency; manual hours returned; data-quality defects caught before production.