Provenance in health data: where did that number come from?

What does it mean to trace a health-data claim?

Start with a plain example. You scan a food package, a search selects a database entry, the entry describes nutrients per serving, and you change the portion to match what you ate. Your diary total now depends on the package match, the source entry, the serving definition, and your portion edit. A mistake at any step can survive into a precise-looking total.

The W3C provenance model describes the entities, activities, and people involved in producing information. In a tracker, the practical equivalent is following a displayed value back through the input and any transformations. This is an explanatory framework, not a claim that Moodwell implements the W3C specification.

• Original source: a label, database, connected service, measurement, or person.
• Identity: the exact product or record that was matched.
• Version: the source date or revision, where available.
• Transformation: unit conversion, portion scaling, normalization, or estimation.
• Remaining uncertainty: missing fields, ambiguous matches, or incomplete inputs.

An interface may expose a short source label rather than this whole chain at once. That can be useful, provided the label means something specific. “Database” is not the same as a named record. “Verified” is incomplete without an explanation of who checked what.

How do DailyMed, RxNorm, openFDA, USDA, and NIH differ?

These names are often placed together as proof of data quality. They serve different jobs. A vocabulary that helps identify a medicine cannot, by itself, answer an interaction question. A label repository describes submitted information; it does not test the contents of the package in your hand.

DailyMed explains that its in-use labeling can differ from the latest approved labeling and that NLM does not review submitted SPL content before publication. RxNorm’s overview describes its role in standardizing names. Those are valuable functions, but they are different functions.

openFDA documents both its labeling source and the limits of relying on that data. USDA’s comparison of food data types distinguishes analytical values from manufacturer label information and other records. The appropriate question is which source supports this particular field.

Why does matching the exact product matter?

A brand name may refer to several products. A medicine can have different strengths, dosage forms, manufacturers, and inactive ingredients. A food can have a different recipe in another market or after reformulation. Searching for a familiar name is the beginning of a match, not the end.

Before interpreting a displayed field, check the identity that produced it. Is the record for the package you have? Does the serving unit make sense? Did a label capture read the decimal and the unit correctly? A correct source attached to the wrong product still produces an incorrect personal record.

For ingredient matching, the spelling on a label and the standardized ingredient concept may also differ. Name normalization can connect known synonyms, but it can lose important detail if it treats all similar strings as equivalent. A salt form, preparation, or combination is not automatically interchangeable with the shorter name a search result displays.

That is why an unmatched item needs to remain visible as unmatched. Silently selecting the nearest familiar result makes the interface easier for a moment and the record harder to trust later. The matching decision belongs in the chain of evidence.

What is the difference between zero, missing, and unchecked?

Zero is a recorded value. Missing means a value was not available. Unchecked means the relevant assessment was not completed. They may all produce an empty-looking cell, but they answer different questions. An app that uses the same display for all three leaves the person guessing.

The same distinction applies to a warning list. No displayed finding may mean none was returned within a defined scope. It may also mean the source could not be queried, the product was unmatched, or the relevant ingredient was unavailable. Those paths need different explanations, even when they all contain zero findings.

When reading a result, look for coverage before reassurance. Which products were identified? Which source was used? Are any items excluded? That is a more useful sequence than treating the absence of a red badge as a complete answer.

How is an estimate different from a measurement?

A measurement comes from an observation or instrument under particular conditions. An estimate is calculated using inputs and assumptions. Both can be useful; neither becomes the other because the interface displays a decimal place. A modeled drug-level curve is not a laboratory test, just as a photo-based portion estimate is not a weighed serving.

For an estimate, provenance includes the inputs and the model. If a recorded event is missing, a timestamp is approximate, or a required parameter is unavailable, the calculation inherits that uncertainty. A polished curve can conceal those dependencies unless the view names them.

A missing half-life is especially easy to mishandle in a timing feature. It does not mean zero, and it does not justify substituting a convenient number without disclosure. When a model cannot be supported, an unavailable state is more informative than a chart that merely looks complete. No curve establishes a personalized dosing decision.

How can you inspect a result without becoming a data engineer?

Follow one claim backward. If a calorie total seems surprising, open the entry and inspect the food, portion, and unit. If an ingredient result seems unexpected, check the exact product and available label. If a pattern seems strong, inspect the days behind it, including empty ones. Each of those checks tests a different link in the chain.

You do not need to distrust every number. You need a way to understand what kind of number it is. A clear source and an editable input let you correct the record. A vague authority badge offers less help because it does not tell you where a mismatch could have happened.

There is also a useful stopping point. If the record cannot resolve a product identity or a health question, more clicking may not supply the missing context. A pharmacist, prescriber, or manufacturer may be the appropriate source for the underlying question. The app can preserve what remains unresolved rather than treating uncertainty as user error.

How does this apply to Moodwell?

Moodwell includes source and coverage information in supported health workflows, review steps for captured food, and modeled information where applicable. The available detail varies by feature and record. This article does not promise a clickable source for every field or complete coverage of every product.

The interaction and allergen page explains documented findings and incomplete-data states. The food tracker shows why reviewing a captured entry matters. For the broader boundary between a readable record and a medical conclusion, see record and reveal.

The order is simple: establish what the record represents, inspect where it came from, then ask what it can support. Starting with the conclusion reverses that order. Provenance gives you a route back.