Skip to main content
U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

NIEM Model

The NIEM model defines agreed-upon terms, definitions, relationships and formats—independent of how information is stored in individual systems—for data being exchanged. It's currently available in XSD and Microsoft Excel formats, as well as in Unified Modeling Language (UML) tools to graphically depict exchanges and the elements of each exchange message.

The Program has published NIEM JSON-LD context online to provide a Uniform Resource Identifier mapping for each namespace in NIEM starting with the 4.0 release. This gives JSON users an easy way for JSON messages to use and reference the model and provides a linked data approach to the already robust capabilities offered by NIEM.

 
 

Model Overview

Model content

Words are to a dictionary as elements are to a reference model. The NIEM model consists of two related vocabularies: core elements that are commonly agreed to by all of the communities who use NIEM, and community-specific elements that align to individual NIEM domains. To learn more about subcommittees, visit the Communities page. You can browse the content in the NIEM model using one of several tools available in the NIEM Tools Catalog.

Picture explaining the organization of the NIEM model into NIEM Core and NIEM Domains. The NIEM Core consists of data elements that are commonly understood and defined across domains. NIEM Domains include mission specific data that is managed through independent stewards. Future Domains added to NIEM as necessary based on an established need.

When using NIEM, you only need to "speak" two languages: your own (system's vocabulary) and NIEM. The NIEM model provides a reference vocabulary for consistent reusable exchanges. When developing information exchanges, agreeing to a common set of data elements and definitions is a frequent challenge. The NIEM model was built to address this challenge. For example, a previous data exchange included four partner organizations. As one of the four partner organizations, you would have had to connect to three different systems and negotiate a common language between them. Now, it's just your language and NIEM. NIEM provides this common vocabulary.

NIEM core

The NIEM core consists of data elements that are commonly understood and defined across subcommittees, such as person, activity, document, location, and item. It’s governed jointly by all NIEM subcommittees.

NIEM subcommittees

NIEM subcommittees contain mission-specific data components that build upon NIEM core concepts and add additional content specific to the community supporting that mission. A NIEM subcommittee represents both the governance and model content oriented around a community’s business needs. A NIEM subcommittee manages their portion of the NIEM data model and works with other NIEM subcommittees to collaboratively to identify areas of overlapping interest. Learn more about how a NIEM subcommittee is governed on the Subcommittee Governance page.

Model architecture

Data components within the NIEM model are represented as elements and types.

Picture showing how data components within the NIEM model are represented. Elements are 1) most common architectural feature of the model 2)compared to a property in object-oriented programming 3) declared as being a certain type. Types are 1) descriptions of a set of nouns 2) analogous to a class in object-oriented programming and contains releated elements. A sample of the architecture is: nc:PersonName at the top of the structure. Under nc:PersonName is nc:PersonNameType. Under nc:PersonNameType is nc:PersonGivenName and nc:PersonSurName. Those are all elements. Under nc:PersonGivenName and nc:PersonSurName are sample types nc:PersonNameTextType nc:ProperNameTextType nc:TextType niem-xsd:string

All NIEM elements follow standard naming rules outlined in the NIEM Naming and Design Rules (NDR). In NIEM, every data element or type is declared in a namespace in order to prevent naming collisions while allowing for proper governance of data concepts. For example, different communities have different definitions of an "address." Namespaces help to identify in which part of the model, core, or individual subcommittee the element or type is located.

Get a more detailed overview on the Model Architecture page.

Model Management

Model Release Cycle process

The NIEM model was designed to accommodate updates on a regular basis in order to evolve with user needs. To incorporate change on a predictable and sustainable schedule, NIEM has a release cycle for model updates.

For each new release, the NIEM Business Architecture Committee (NBAC), NIEM Technical Architecture Committee (NTAC), and NIEM community work together to update the model.

The current release is NIEM version 5.0.

NIEM’s Release Cycle is broken into Major and Minor Releases. A Major Release can be expected every three years, with a minor release potentially occurring every 12 months. A Major and Minor Release will not occur in the same calendar year. This process ensures that NIEM addresses community business requirements.

  • Major Releases occur when the NIEM core and subcommittees are updated and then synchronized. Any technical architecture changes to the model are exclusively made during a Major Release. Major Releases are given version IDs such as 2.0, 3.0, 4.0, or 5.0.
  • Minor Releases occur to incorporate and synchronize changes to subcommittee content, and may contain core supplements. Minor Releases are given version IDs such as 2.1, 2.2, 3.1, or 3.2.
  • Core supplements are a special type of NIEM release that allow the program flexibility to apply strictly additive changes to a previously published NIEM core. A core supplement (CS) can be issued when the NBAC determines it is necessary to add content to a published NIEM core. A CS does not have to be issued within a major or minor release cycle, although it can be. The purpose for issuing a CS may include:
    • Updating a code list with new values added by an authoritative source
    • Correcting a significant flaw in a component, to add a new element to a substitution group
    • Applying other adjustments by adding content

Picture showing when NIEM has issued releases in the past. In 2006, NIEM issued version 1.0 a major release. In 2007, NIEM issued version 2.0 a major release. In 2009, NIEM issued version 2.1 a minor release. In 2013, NIEM issued version 3.0 a major release. In 2014, NIEM issued version 3.1 a minor release. In 2015, NIEM issuesd version 3.2 a minor release. Between 2015 and 2016, NIEM issued two Core Supplements (or special releases) 3.0.1 and 3.0.2. In 2016, NIEM also released core supplement 3.0.3. In 2017, NIEM issued version 4.0 a major release. In 2018, NIEM issued version 4.1 a minor release. In 2019, NIEM issued version 4.2 a minor release.

Learn more about core supplements and how to use them.

Updating subcommittee models

The NIEM model is decentralized, such that individual NIEM subcommittees manage their respective subcommittee updates—these can happen at any time. If a data requirement isn't already found in the model and is specific to a particular community, a request can be made to the subcommittee's point of contact for consideration for the subcommittee. The approved updates are then incorporated into the next NIEM release (major or minor) for reconciliation and official publication.

Updating the NIEM core

If a data requirement isn't already found in the overall NIEM model and is applicable to many subcommittees, it can be submitted through the NBAC for consideration for NIEM core. A primary function of the NBAC is to coordinate the ongoing harmonization process between NIEM core and subcommittees.

Model harmonization

Harmonization is an ongoing process to ensure no duplication in the model as updates are made and it evolves to accommodate new community business requirements. The harmonization process integrates these new requirements while still ensuring data elements exist only once in the model. There are two types of harmonization, between subcommittees and between NIEM core and subcommittees.

Harmonization review process

Each subcommittee has its own process for updating its data model, depending on the subcommittee’s business needs and resources available.

For harmonization between NIEM core and subcommittees, every new business requirement that's identified follows a review process, as follows:

  1. Issue is identified and an initial assessment is conducted by the NIEM lead developers or self-identified by the subcommittee(s).
  2. Issue is reviewed by the NBAC and is assigned to a team consisting of NBAC members with knowledge, expertise, and/or vested interest in resolving the issue.
  3. The NBAC team works to resolve the issue and provides a recommended solution.
  4. The NBAC reviews the recommended solution and accepts, rejects, or defers it for more information, which the team then supports.
  5. When the solution is accepted, NIEM lead developers will include it in the next release (major or minor).

Harmonization is an important activity and is part of the NIEM release cycle for that helps keeps the model easy for developers and business leaders to navigate and use.