The NEMSIS data dictionary is the element-by-element specification of what an ePCR must record, and reading it as an implementer rather than as a reference document takes a little orientation. Elements are grouped into sections that map to the shape of a call — dispatch, patient, situation, vitals, medications, procedures, disposition — and each carries a usage rule that matters more than its definition: required elements must be present for a submission to validate, conditional elements become required when a specific circumstance applies, and recommended elements are optional nationally but frequently mandatory in a given state. That last distinction causes most of the confusion, because software that validates cleanly against the national schema can still be rejected by a state repository that requires elements the national standard treats as optional.

How the Dictionary Is Organised

The NEMSIS data dictionary groups elements into sections that mirror the actual shape of an EMS call, roughly in the order a crew would document it: dispatch information, patient demographics, situation and chief complaint, vitals and assessment, medications and procedures administered, and disposition. That structure is worth internalizing before you start reading individual element definitions, because it tells you where to look for a given piece of data without hunting the whole document.

This is the distinction that causes most of the confusion in the field, and it’s worth being precise about each tier:

  • Required — must be present on every submission, or the record fails national validation outright.
  • Conditional — becomes required when a specific documented circumstance applies (for example, an element that’s only required if a particular medication was administered). Software has to correctly detect the triggering condition, not just the element itself.
  • Recommended — optional at the national level, but this is exactly where the trap lives: a state repository frequently makes a nationally-recommended element mandatory for its own submissions.

A record that validates cleanly against the national schema, using only required and correctly-triggered conditional elements, can still be rejected by a specific state’s repository if that state has elevated a recommended element to mandatory. This is the single most common source of “but it passed national validation” confusion.

National Elements vs. State Additions

Every state EMS office has the latitude to layer its own additional required elements on top of the national NEMSIS baseline — which is exactly why I stress in the main NEMSIS post that “NEMSIS compliant” needs a state-specific follow-up question. A software product genuinely certified against the national standard can still fail submissions in a specific state until it’s also configured for that state’s additional requirements. Confirm this distinction explicitly during any software evaluation — ask for state-specific validation evidence, not just national compliance testing status.

Reading an Element Definition

Walking through one concrete example end to end: a vitals element carries a defined data type, a usage tier (required/conditional/recommended), a valid value set or code system it must draw from, and often a specific unit of measure. Getting any one of those wrong — submitting a value outside the defined set, using the wrong unit, or missing the element’s specific trigger condition if it’s conditional — produces a validation failure, even when the underlying clinical data is perfectly accurate. The dictionary is unforgiving about form in a way that has nothing to do with clinical correctness, and that gap is worth understanding going in.

The Elements That Cause the Most Trouble

From an implementer’s perspective, trouble concentrates in a predictable place: conditional elements whose trigger logic is genuinely ambiguous in edge cases, elements tied to a code set that gets revised between versions, and — the pattern already covered above — nationally-recommended elements a given state has quietly made mandatory. None of these show up as obviously “hard” reading the dictionary casually; they show up as hard when real, messy field data hits them.

Version Differences That Matter

Verify the current NEMSIS version and build against nemsis.org directly — the standard is actively maintained with incremental patches, and an element’s usage tier, valid value set, or very existence can change between versions. Software that hasn’t kept pace with the current version is exactly the scenario that produces validation failures that didn’t exist the month before, through no change on the software’s own side.

Next Steps

Reading the NEMSIS data dictionary as an implementer — usage tier first, state additions second, version currency always — is a genuinely learnable skill, and it’s the foundation everything else in ePCR software development sits on. If you’re building an ePCR or extending one and want to talk through the specific elements your build needs to handle, see our post on what building a custom ePCR actually takes, or talk to our team directly.