ICD 10 Nausea and Vomiting Code Guide for 2026

When it comes to coding for nausea and vomiting in ICD-10-CM, your starting point will almost always be the R11 series. The three most common codes you'll encounter are R11.0 for nausea, R11.10 for vomiting without further specification, and R11.2 for when the patient experiences both nausea and vomiting. Getting this right is fundamental for everything from billing to large-scale clinical analytics.

Decoding the ICD-10 R11 Code Series

For anyone who works with clinical data-coders, analysts, and data engineers alike-a solid grasp of the R11 series is non-negotiable. These codes fall under Chapter 18: "Symptoms, Signs, and Abnormal Clinical and Laboratory Findings," which is a crucial distinction.

They are symptom codes. That means they capture what the patient is feeling, not why they are feeling it. This detail is absolutely essential for creating a clean, accurate clinical picture in the data. For a deeper dive specifically on nausea without vomiting, you can refer to our guide on ICD 10 codes for nausea.

Clinical and Data Significance

The level of detail you choose has real-world consequences for reimbursement and the quality of your analytical data. For example, using a specific code like R11.12 for projectile vomiting paints a much clearer clinical picture than the vague R11.10.

One of the most important rules of thumb in clinical coding is that R11 codes are typically secondary diagnoses. If you can identify the primary cause-like gastroenteritis (A09), for instance-that condition must be coded first. This sequencing makes it clear that nausea or vomiting is a manifestation of an underlying disease. If you're looking for more best practices, there are some great nausea and vomiting documentation guidelines on s10.ai that are worth a read.

This coding hierarchy is especially relevant for data professionals who use the OMOP Common Data Model. If the source data is coded correctly, mapping these symptom concepts in your ETL process becomes far more reliable. This work, often done through platforms like OMOPHub, ensures that the resulting analytics are built on a foundation that respects the original clinical intent.

Quick Reference for R11 to OMOP Mapping

When you're working with clinical data, translating source codes like the ICD 10 nausea and vomiting series into a standardized format is a foundational step. Getting the mapping right between a source code and its corresponding OMOP Common Data Model (CDM) concept is what makes large-scale, network analytics possible.

At its core, this process harmonizes the meaning of a code across entirely different datasets. For instance, the ICD-10-CM code R11.2 (Nausea with vomiting, unspecified) gets mapped to a single standard concept that also represents the same clinical idea from other terminologies, like SNOMED CT. This is how we ensure we're all talking about the same thing.

ICD-10-CM to OMOP Concept Mapping for Nausea & Vomiting

To make this concrete, here's a lookup table that directly connects the most common R11 codes to their OMOP Standard Concept IDs and SNOMED CT equivalents. This is the kind of reference you'll want handy when building out an ETL or trying to define a precise patient cohort.

ICD-10-CM Code	Official Description	OMOP Concept ID	SNOMED CT Concept
R11.0	Nausea	432585	Nausea (finding)
R11.10	Vomiting, unspecified	196523	Vomiting (finding)
R11.11	Vomiting without nausea	45769225	Vomiting without nausea
R11.12	Projectile vomiting	435213	Projectile vomiting
R11.2	Nausea with vomiting	197485	Nausea and vomiting

Pro Tip: While this table is a great starting point, always verify concept relationships programmatically. Vocabularies are updated regularly. Using the omophub-python or omophub-R SDKs to automate lookups ensures your mappings remain current. For quick manual checks, use the OMOPHub Concept Lookup tool.

Having this mapping is a great start, but a word of advice from experience: always ensure your ETL logic points source codes to their designated OMOP Standard concepts. It's a critical step for aligning your data with OHDSI network research standards.

Navigating R11 Coding Exclusions

When you're dealing with medical codes, knowing what not to use is just as important as knowing what to use. This is especially true for the ICD-10-CM nausea and vomiting codes in the R11 series, where "Excludes1" notes are the rule of the road.

An Excludes1 note isn't a suggestion; it's a hard stop. It means two conditions are mutually exclusive, so you can't report both codes together. If a patient's nausea and vomiting are clearly a symptom of a more specific underlying condition listed in an Excludes1 note, you must code that primary condition instead. Getting this right is fundamental for building accurate ETL pipelines and defining reliable patient cohorts.

Key Excludes1 Conditions for R11

The R11 category explicitly carves out several conditions. I’ve seen countless coding errors and data quality issues stem from misinterpreting these rules. Here are some of the most common exclusions you need to watch out for:

• Cyclical Vomiting in Migraine: If vomiting is a documented feature of a patient's migraine, you'll need to use a code from the G43.A- series instead of R11.
• Hyperemesis Gravidarum: For excessive vomiting during pregnancy, the correct codes are found in the O21.- series.
• Psychogenic Vomiting: When vomiting is tied to a psychological diagnosis, the proper code is F50.89.
• Vomiting After GI Surgery: Post-operative vomiting has its own specific code, K91.0. Don't use an R11 code in this scenario.

This decision tree gives a good visual for the initial thought process when a patient presents with these symptoms.

As the graphic shows, your first step is always to determine if the nausea or vomiting is an isolated symptom or just one piece of a larger, more specific diagnosis-which might be an exclusion.

The list of exclusions for the R11 category is actually quite extensive, covering everything from neonatal vomiting (P92.0-) to vomiting of blood, or hematemesis (K92.0). These rules are there for a reason; they reflect the clinical reality that nausea and vomiting can stem from a wide array of causes that demand a more precise primary diagnosis. For any data team building an ETL process, respecting these exclusions is non-negotiable for ensuring accurate vocabulary mapping and preventing data contamination down the line. You can review a complete list of these exclusions in the official ICD-10-CM guidelines or get more details about the R11 code on AAPC.com.

Bridging Gaps in Clinical Documentation

Anyone working in healthcare analytics knows the frustration of trying to align unstructured clinical narratives with structured billing data. A physician’s note might paint a clear picture of a patient's struggles with nausea, but that critical detail often gets lost in translation and never becomes a specific ICD 10 nausea and vomiting code on the claim.

This documentation gap is a major source of data quality problems, particularly when tracking complex conditions like Chemotherapy-Induced Nausea and Vomiting (CINV). The discrepancy isn't just theoretical; research into pediatric and young adult oncology records has put hard numbers on the problem.

One study of 127 patient encounters found that while 64% of cases had clinical notes clearly documenting CINV, only 16% had a corresponding ICD-10 code. This is a massive loss of structured data. Interestingly, when codes were used, they showed an 85% agreement with the provider's assessment, proving their value when applied correctly. You can dig into the full analysis of this data quality challenge on PMC.

For data engineers and machine learning teams, this means that relying on billing codes alone gives you a dangerously incomplete view. The real story is often buried deep inside the clinical text.

Strategies for Data Completeness

To build a truly accurate patient cohort, your team needs to move beyond simple code lookups and find ways to bridge this documentation gap. Here are a couple of effective strategies that have worked in practice:

• Natural Language Processing (NLP): Use NLP models to scan clinical notes for mentions of symptoms like nausea and vomiting. This is the most direct way to surface evidence of a condition that was never formally coded.
• Concept Set Validation: Never assume your code list is comprehensive. After building a cohort based on your ICD 10 nausea and vomiting concept set, validate it against a second cohort identified using NLP. This cross-check will quickly tell you if your code-based approach is missing a significant part of the true patient population.

How OMOPHub Supports Data Integrity

Executing these advanced strategies is nearly impossible without a solid vocabulary service. A platform like OMOPHub is built for this, providing the technical foundation for creating comprehensive data mappings.

With a tool like OMOPHub, you can programmatically explore the entire hierarchy of ICD 10 nausea and vomiting codes and see their relationships to other standard vocabularies like SNOMED CT. For a technical deep-dive, the official documentation on using LLMs and vocabulary services is a great resource. This capability allows your team to build more sophisticated ETL pipelines that enrich structured data with insights from clinical text, which is the key to improving the accuracy and reliability of your analytics.

Automating Concept Lookups with the OMOPHub API

While you can always look up a single code by hand, that approach just doesn't scale. For anyone building maintainable data pipelines, automating your vocabulary management is non-negotiable. This is where the OMOPHub API comes in, giving you the tools to programmatically query codes like the ICD 10 nausea and vomiting series. The payoff is huge: you save countless hours and dramatically cut down on manual errors.

This section gets right into the practical application, providing hands-on examples using our official SDKs. If you're an ETL developer or responsible for terminology mapping, these snippets show exactly how to fetch OMOP Concept IDs, check relationships, and validate your work. And for those times you just need a quick, one-off search, our OMOPHub Concept Lookup tool is always ready on the website.

Using the Python SDK for Concept Lookups

The omophub-python SDK makes it incredibly easy to pull OMOP vocabulary lookups directly into any Python application. Once you've installed the library and have your API key, you can get all the details for a concept with just a few lines of code.

Here’s a real-world example showing how to query the ICD-10-CM code R11.2 (Nausea with vomiting, unspecified):

from omophub import OmopHub

# Initialize with your API key
oh = OmopHub(api_key='YOUR_API_KEY')

# Look up an ICD-10-CM code
concept_details = oh.get_concept_by_name(concept_name='R11.2', vocabulary_id='ICD10CM')

# Print the results
print(concept_details)

This script does a few key things. It authenticates with the API, searches for the R11.2 concept specifically within the ICD10CM vocabulary, and prints a JSON object with the concept_id, concept_name, domain_id, and other vital attributes. It’s the perfect starting point for building an automated mapping file. For more advanced techniques, the official documentation on using LLMs and vocabularies has you covered.

Performing Lookups with the R SDK

For teams that live in the R ecosystem, the omophub-R SDK offers the same powerful functionality. It’s a go-to tool for the clinical researchers and biostatisticians who rely on R for their data analysis.

The process is just as direct. Install the library, configure your API key, and you can run the same lookup for R11.2 in a matter of seconds.

library(omophub)

# Set your API key
set_api_key("YOUR_API_KEY")

# Look up an ICD-10-CM code
concept_details <- get_concept_by_name(concept_name = "R11.2", vocabulary_id = "ICD10CM")

# View the results
print(concept_details)

Making these lookups an automated part of your process is fundamental to good data governance. It guarantees your mappings are always aligned with the latest vocabulary versions available through OMOPHub. By embedding these simple scripts into your ETL or data validation workflows, you can systematically translate source codes into standard concepts-an essential step for any serious OMOP project. To dig deeper into this, take a look at our guide on the ICD 10 codes converter.

Building an ETL Mapping for Nausea and Vomiting

The technical core of loading clinical data into the OMOP CDM is the ETL mapping process. For symptoms like nausea and vomiting, this all comes down to systematically converting source codes, such as the ICD 10 nausea and vomiting R11 series, into their corresponding OMOP standard concepts. A well-constructed mapping file isn't just a one-off task; it's a living document that keeps your data accurate, consistent, and ready for research.

Think of this process as creating the definitive blueprint for how your data warehouse will represent these common symptoms. When you get it right, an analyst can query for "nausea and vomiting" and pull every relevant patient, no matter if their source record used an ICD-10, SNOMED, or some other proprietary code. For automating the creation of this source-to-standard mapping, the OMOPHub API is an incredibly effective tool.

A Programmatic Approach to Mapping

Manually building a mapping file for every possible ICD 10 nausea and vomiting code is not just inefficient, it's an open invitation for errors. A far more robust approach is to programmatically fetch all relevant source codes and their standard concept mappings. This gives you a scalable and repeatable process that can be easily updated as vocabularies evolve.

The Python script below shows how to use the omophub-python SDK to find all descendant concepts of "Nausea and vomiting." From there, it creates a dictionary that maps source ICD-10-CM codes directly to their standard OMOP concept IDs.

from omophub import OmopHub

oh = OmopHub(api_key='YOUR_API_KEY')

# First, find the parent standard concept for "Nausea and vomiting"
# The concept we search for here is from SNOMED, which is a standard vocabulary
parent_concept = oh.get_concept_by_name('Nausea and vomiting')
parent_id = parent_concept['concept_id']

# Get all source concepts that map to this standard concept or its children
descendants = oh.get_descendants(concept_id=parent_id)

# Filter for ICD-10-CM source codes and create a mapping to their standard concept IDs
# A source concept's 'standard_concept_id' attribute gives us the correct mapping target
icd10cm_map = {
    c['concept_code']: c['standard_concept_id']
    for c in descendants
    if c['vocabulary_id'] == 'ICD10CM'
}

print(icd10cm_map)

This simple script automates the hard work of building your mapping logic. It ensures that your source codes are correctly translated before they ever land in the condition_occurrence table.

Pro Tip: Your ETL logic absolutely must account for source codes that don't have a direct mapping to a standard concept. These "unmapped" codes should be logged and flagged for review by a subject matter expert. For a much deeper dive into the mechanics, you can find more in the OMOPHub LLM documentation.

Mapping Best Practices

To make sure your ETL process is both accurate and maintainable over the long haul, stick to these fundamental principles:

• Handle Non-Standard Codes: Always map source codes to their standard OMOP concept ID. This is the non-negotiable foundation of the OMOP CDM.
• Manage Vocabulary Versions: Vocabularies are updated all the time. Your mapping process needs to be re-runnable to pick up new or modified codes.
• Target the Right Table: For diagnoses and symptoms, the destination is almost always the condition_occurrence table. The standard concept ID should be stored in the condition_concept_id field.

By establishing a durable and automated ETL mapping process, you lay the groundwork for trustworthy and powerful clinical analytics. For more on this subject, take a look at our guide on mapping in ETL for healthcare data.

Frequently Asked Questions About R11 Coding

Working with the ICD-10 nausea and vomiting R11 code series, you'll inevitably run into a few common questions. Let's tackle some of the most frequent sticking points for coders, analysts, and data engineers in both clinical coding and OMOP vocabulary work.

What Is the Correct Code for 'Nausea/Vomiting'?

When the clinical notes simply say "nausea and vomiting," the best practice is to use R11.2 (Nausea with vomiting, unspecified).

This is a much better choice than assigning R11.0 (Nausea) and R11.10 (Vomiting, unspecified) separately. The combined code R11.2 more accurately reflects the patient’s concurrent symptoms as documented.

When Should R11 Codes Be a Primary Diagnosis?

This is a critical point for proper billing and data integrity. An R11 code should only be the primary diagnosis if the nausea or vomiting is the main reason for the visit and a more definitive cause hasn't been found yet.

Once a root cause like gastroenteritis is diagnosed, that condition gets sequenced first. The R11 code can then be used as a secondary diagnosis, which adds valuable detail about the patient's specific symptoms during the encounter.

Can OMOPHub Find Related Pediatric or Pregnancy Codes?

Absolutely. This is exactly where the OMOPHub API shines, as it's built to explore these kinds of complex vocabulary relationships. You could start with a general concept like "Nausea and vomiting" and then programmatically walk the vocabulary hierarchy to find related codes or, just as importantly, codes that are excluded.

This approach lets you easily identify specific code sets such as:

• Pregnancy-related codes like the O21.- series for hyperemesis gravidarum.
• Newborn-specific codes, including the P92.0- series for vomiting in newborns.

This is a far more robust method for building ETL logic that correctly handles the "Excludes1" notes found throughout ICD-10-CM. You can see detailed examples of how to traverse these relationships in the official OMOPHub documentation.

---

At OMOPHub, we provide the developer-first vocabulary tools you need to build accurate, scalable, and compliant healthcare data solutions. Stop wrestling with local database setups and start shipping faster. Explore our services and get your free API key at https://omophub.com.