How MEV Built Privacy-Preserving Patient Matching for Tokenized Pharmacy Claims

Client:

Healthcare technology company

Industry:

Healthcare / Pharmacy claims and coverage workflows

Focus:

Matching patient lookup requests against tokenized pharmacy claims without storing raw PII

Technologies:

REST API / Datavant / Snowflake / SingleStore / AWS

[ about the client/ ]

The client is a healthcare technology company building a platform for real-time pharmacy coverage lookup.

The product needed to help identify a patient’s drug coverage at the pharmacy counter, even when the patient presents the wrong insurance card or does not know their plan. To do that, the platform had to match temporary patient inputs against tokenized pharmacy claims history while keeping raw personal data out of persistent storage.

What Needed to Be Done

The platform needed a way to identify likely drug coverage using limited patient information during an API request.

The challenge was that the incoming pharmacy claims data was already de-identified. The system could not simply store raw patient data and match against it later. It had to compare live patient inputs to tokenized claims histories without persisting raw PII.

The job was to design a matching flow where the API could briefly accept only the minimum identity fields needed for matching:

name
date of birth
ZIP code
gender

These inputs had to be tokenized during the request, compared against tokenized claims records, and discarded immediately after the match process.

Why It Mattered

Coverage lookup only works if the system can connect a live patient request to the right claims history. But in healthcare, that connection has to be handled carefully. Keeping raw PII in the platform would increase privacy, security, and governance risk. At the same time, removing identity data completely would make accurate coverage lookup impossible.

The architecture needed to preserve both sides:

Enough identity signal to support coverage matching. The system had to identify likely coverage from pharmacy claims history.
Strong privacy discipline around patient inputs. Raw PII had to remain transient and never become stored platform data.

This let the product support pharmacy-counter lookup without turning temporary patient details into a long-term data liability.

What MEV Built

MEV built a privacy-preserving identity matching flow for pharmacy claims lookup.

Claims data stayed tokenized throughout the platform. When an API request came in, the system accepted only the minimum patient details required for matching, sent those details through the same Datavant tokenization process, and generated comparable tokens. Those tokens were matched against tokenized claims history to identify likely drug coverage.

Raw PII was discarded immediately and never written to disk or stored in the system.

The matching flow worked alongside the broader platform architecture: Snowflake prepared and validated claims data, curated outputs moved through AWS, and the serving layer supported API lookup.

Technical Flow

01:

Tokenized claims data enters the platform

The platform receives de-identified pharmacy claims data. Patient identity is represented through tokens rather than stored raw PII.

02:

API request collects minimum required inputs

When a coverage lookup request comes in, the API briefly accepts only the patient details needed for matching: name, date of birth, ZIP code, and gender.

03:

Patient inputs are tokenized at request time

The system sends the temporary patient inputs through the same Datavant tokenization process used for the claims data.

04:

Tokens are compared against claims history

The generated tokens are matched against tokenized pharmacy claims records to identify likely coverage.

05:

Coverage result is returned through the API

Once the match is found, the API returns the coverage lookup result needed for the pharmacy workflow.

06:

Raw PII is discarded immediately

The original patient inputs are not written to disk and are not stored in the platform.

07:

Claims data remains tokenized

The platform continues operating on tokenized claims data, keeping identity matching useful without making raw PII part of persistent system storage.

Outcome

The client gained a privacy-preserving lookup flow for pharmacy claims coverage.

The platform could match live patient inputs against tokenized claims histories without storing raw PII. This made it possible to support real-time coverage lookup while keeping the system’s identity handling tighter and safer.

The result was a matching architecture that supported the product’s core use case: identifying likely PBM or plan coverage at the pharmacy counter, even when the patient provides incomplete or incorrect insurance information.

This case is part of the full case study

Building a Snowflake-Based Pharmacy Claims Platform for Real-Time Drug Coverage Lookup

[ portfolio/ ]