A platform that helps contact dermatitis patients manage everyday life

How does the platform help patients day to day?

Without a platform like this, a patient leaves the clinic with a list of allergens and has to check product labels for them every time they shop. Miss one and the reaction can come back. The platform makes that easier. A physician patch tests the patient, enters the allergens, and the platform creates a personal list of products that do not contain them. The patient can use the app or website to search by type, brand or name, or scan a barcode while shopping and get an answer right away.

The product list now has more than 150,000 products. Patients and clinicians can suggest new products, report discontinued ones and rate products they use, helping keep the list current. Each allergen also has educational material explaining what the patient is avoiding and why. The platform tracks the effect of the condition on quality of life over time using questions set by the society, giving both the patient and physician a way to see how things are changing.

The ingredient data matters because it affects what a patient is told they can safely use. If the data is wrong, an unsuitable product can make its way onto a patient's list. If it is right, the patient has one less thing to worry about.

What did Sequoia build?

The society already had a version of the platform, but the software and interfaces were dated. The mobile site and app had also moved in different directions. Patients had no built in way to provide feedback, the product list needed to expand, and the experience needed to work better for both patients and clinicians. We built the platform they use today, including the web application for patients and physicians, the iPhone and Android apps, and the admin site used by the society.

The build covers the following areas from the society's brief:

The engagement is ongoing. The platform is live and in use, and we continue to extend it. This page focuses on the part of the work that became central to everything else: the ingredient data.

Why was the ingredient data difficult to work with?

Product data comes from a third party API. The ingredient lists in that feed are read from packaging using OCR, and the results are not always clean. Some strings had stray special characters. Several ingredients were combined into one entry when punctuation was lost. The same ingredient could also appear with different spellings or naming conventions.

Each variation was treated as a separate ingredient, and the table grew to around 140,000 unique names.

That creates a bigger problem here than it would in an ordinary product catalogue. The safe list works by excluding products that contain a patient's allergens. If the physician's allergen and the product ingredient use different names, the match can fail and an unsuitable product can appear on the list. Search has the same problem. A patient searching for an ingredient should not have to choose between a dozen versions of the same name.

Cleaning 140,000 strings by hand was not practical. Rule based cleaning handled the common cases, but it stopped being useful once we reached the long tail, where the problems varied from one string to the next.

How did AI reduce 140,000 names to 40,000?

We ran two language model passes across the ingredient table.

The number of unique ingredients fell from about 140,000 to about 40,000. Search became cleaner, matching became more consistent, and the ingredient table became much easier for the society's admins to manage.

On models: we used a mix of OpenAI models and self hosted open weight models, picked per activity. Some parsing and standardisation work runs on hosted models, some on models we run ourselves. Which one gets which job is a cost, volume and data handling decision, and it is the kind of choice our AI for life sciences team makes on most engagements now.

What else sits around the data work?

Clean ingredient data is the foundation, but it is only one part of the platform. The product data API supplies names, ingredients, categories, manufacturers, images and UPC codes on a regular refresh, so the catalogue can grow without manual entry. Products already in the system that are not in the API are migrated and brought into the same structure.

Search uses one page with fuzzy matching, spelling tolerance and predictions, so patients and physicians can type part of a name and find the right ingredient. Any ingredient in the system can be selected as a potential allergen. Barcode scanning lets a patient check a product while shopping.

The admin site handles products, ingredients, cross reactor and synonym lists, users and reports. The platform also includes notifications when a patient's list changes, patient feedback with photo upload, education content and quality of life tracking. The web application and mobile apps use the same overall interface, and the brief calls for hosting that meets HIPAA requirements. The mobile work follows the same practical approach we use in our medical device engineering work, where a patient facing app needs to be straightforward and difficult to misread.

What does this mean if you have a similar dataset?

If you have a reference table that has grown from OCR, user entry or several vendors using different conventions, you may have a similar problem. Rules can clean the common cases. The harder work is usually in the long tail, where the duplicates and inconsistent entries tend to accumulate.

There are two practical points to keep in mind. A model can map a name incorrectly, so the output needs a review process and an approved or unapproved status for each record. That is how the admin site handles new ingredients here. Standardisation also depends on having a standard to map to. INCI exists for cosmetics, but another domain may require you to choose or create one first.

The choice between hosted and self hosted models comes down to volume, cost per record and where the data can be processed. We use both. The same team handles the cloud and data platform side, so the pipeline that feeds the models and the tables they write to are one piece of work rather than two vendors.

Questions people ask about this work

Building something patients will use every day?

Tell us what the platform needs to do for patients and what data sits underneath it. We will come back with an approach and an estimate.