These are the major sections of this website. Expand each sub-section to see the pages within.
NIEM training information, tailored to specific user roles.
A domain modeler creates and manages the content in a NIEM domain.
An Information Exchange Package Documentation (IEPD) Developer designs, builds, and validates the components (artifacts) of an Information Exchange Package (IEP).
The scenario planning phase is the first step you take in IEPD development.
The analyze requirements phase is the next step you take in IEPD development.
During the map and model phase, you compare your information exchange requirements to what's in NIEM, and then define a mapping between your requirements and NIEM content. You use a mapping document, which may be a spreadsheet or similar tabular form.
During the build and validate phase, you create XML schemas and artifacts and verify they meet NIEM standards.
Assemble and Document is the next phase in IEPD development after the Build and Validate phase.
The publish and implement phase is the last phase of IEPD development.
This tutorial shows you how to create a very simple [IEPD](../../../reference/iepd/ "IEPD"). Once you are comfortable with the process and output, you can move on to more complex IEPDs.
An IEPD implementer exchanges information based on the format, rules, and guidance provided by an existing IEPD specification.
A catalog of techniques and methods that help to implement NIEM.
This is a Java project on GitHub that uses Maven and JAXB to generate a jar of java class files based on an IEPD that can be used to read and generate instances.
Learn more about NIEM, including the model, IEPDs, tools, and specifications.
Learn about the kinds of files that make up NIEM releases and IEPDs.
NIEM Code Lists are special files that support the use of enhanced code lists in NIEM, beyond the basic capabilities provided by XML and JSON schema enumerations.
A JSON-LD context file is a file that can be used to associate namespace prefixes with the full URIs that they represent.
An XML catalog is a XML document that assigns locations to files. This can be used to override the file locations assigned by NIEM XML schema import statements without having to modify the original schema itself.
Learn about properties, types, augmentations, and other building blocks used to construct the model.
A namespace is a collection of properties and types, managed by a common authoritative source.
A property represents a concept, idea, or thing.
An element represents a concept. In an instance, it acts as a container that may carry either a simple value or an object, and optionally attributes.
An abstract element is an element defined as a placeholder in a schema that must be replaced with an appropriate substitution in an instance.
A substitutable element is one that can replace another element in an instance.
An attribute is a property that may carry a simple value only.
A type represents a data structure that defines a set of allowable values.
A complex type with complex content (CCC) is a structure that represents an object and may contain elements and attributes.
A complex type with simple content (CSC) is a structure that represents a simple value and that may optionally contain attributes.
A simple type is a structure that represents a simple value only.
A facet is a constraint on a simple type that limits the set of allowable values.
An adapter is a mechanism to use components from a non-conformant external standard within a NIEM-conformant namespace.
An association is a complex relationship between objects, with optional additional characteristics.
An augmentation is a mechanism to add additional local content to NIEM types defined in other namespaces.
An augmentation point is a special substitution group to allow for later replacement by additional content from other namespaces.
An augmentation element is additional content that replaces an augmentation point defined in another namespace.
Local terminology is a word, phrase, abbreviation, acronym, jargon, or other string of characters specially documented in a namespace because no definition or literal exists in a standard dictionary.
Metadata is a set of data that describes characteristics of other data.
A reference is used to link to content defined elsewhere.
The representation pattern is a mechanism to support multiple representations of a concept, along with additional properties.
A role is a function or responsibility of someone or something.
A high-level perspective on the kinds of content that appear in Core and the domains.
An Information Exchange Package Documentation (IEPD) is a collection of NIEM artifacts. They define and describe the context, content, semantics, and structure of one or more implementable information exchanges.
An Information Exchange Package Documentation (IEPD) developer designs, builds, and validates the components (artifacts) of an Information Exchange Package(IEP). The process consists of a six-phase lifecycle.
Review background information related to your information exchange, assess resource impact, understand business context, and identify information exchange business scenarios.
Further elaborate on the information exchange scenario to understand and document the data requirements and business rules.
Review the data requirements captured during the previous phase and discover if there are similar components in NIEM. Document results in a mapping spreadsheet. Begin modeling the data requirements without a match in NIEM; these will be later added added to the IEPD as extensions.
Create subset schemas, and extension schemas, and sample instances based on the previous mapping and modeling work. Verify that schemas and instances are valid and that they meet NIEM conformance requirements described by the NIEM Naming and Design Rules (NDR) specification.
Create any additional documentation needed for the IEPD, fill out the IEPD catalog, assemble all of the artifacts, and bundle the files into the final IEPD zip file package.
Publish the IEPD for search, discovery, and reuse, and implement the IEPD for production.
Each IEPD is a package that contains schemas and other supporting files.
A subset schema is a customized version of a NIEM schema that contains only the properties, types, and codes that are needed for a particular information exchange, plus any of their required dependencies.
In an extension schema, an IEPD developer can create new NIEM-conformant properties and types to represent message data requirements that are not available in a NIEM release. Extensions schemas are used in combination with NIEM subset schemas to define the structure and meaning of a message.
An IEPD Catalog is an XML document that contains basic information about the package (name, description, purpose, etc.) and a listing of the package's key artifacts. It is a required artifact in an IEPD.
A conformance report specifies how and to what degree the IEPD is NIEM-conformant.
A mapping spreadsheet can be used to explicitly document mappings from data requirements to properties and types in NIEM. It can also be used to model extensions for requirements that do not exist in NIEM.
Learn about NIEM IEPD conformance, view sample IEPDs, and more.
Examples designed to demonstrate various unique aspects of the NIEM technical framework.
A list of terms with links to their source definitions across the following technical specifications.
Reusable XML snippets of the various NIEM XML components. These snippets could also be called patterns or templates.
Best practices for NIEM IEPD change control and version management.
A NIEM release is a coherent set of schemas and supporting artifacts representing a specific version of the NIEM data model, published by the NIEM Management Office. Release schemas contain reusable properties and types meant for use in information exchanges. These schemas include NIEM Core, domains, and code tables.
A Core Supplement is an incremental NIEM release that contains new or updated components for the NIEM Core namespace. These changes are published in separate schemas that can be used in addition to the original Core namespace. Core Supplements are used as a way of 'adjusting' Core content while it is locked between major releases.
A domain update is one or more schemas that constitute changes to a NIEM domain outside of the standard NIEM release cycle.
Each NIEM release comes bundled as a zip file containing schemas and other supporting files.
Information about NIEM release change control and version management.
NIEM specifications provide rules and guidance in order to design consistent and well-defined information exchanges. Specifications are managed by the NIEM Technical Architecture Committee (NTAC).
View and search rule sets from NIEM specifications. Filter results by conformance target.
The NIEM Naming and Design Rules (NDR) describe the architecture of the NIEM data model and its representation in XML. It specifies principles and enforceable rules for NIEM data components and schemas.
The NIEM Naming and Design Rules Specification is updated with major NIEM releases, occurring every three years. The following highlights the changes that have been made.
The NIEM Naming and Design Rules defines two classes of conformant XML Schema documents: reference schema documents (REF) and extension schema documents (EXT). View the key rule differences between the two conformance targets.
The NIEM Information Exchange Package Documentation (IEPD) Specification specifies normative rules and non-normative guidance for building NIEM information exchange messages. It defines IEPD artifacts like subset schemas, extension schemas, and IEPD catalogs; and recommends how the package should be structured.
The NIEM Information Exchange Package Documentation (IEPD) Specification can be updated with major NIEM releases, occurring every three years. The following highlights the changes that have been made.
The Conformance Specification specifies general conformance guidance, principles, and rules for NIEM.
The Conformance Targets Attribute Specification (CTAS) defines how NIEM XML documents classify what kind of artifact they are through the use of a conformance targets attribute.
The Code Lists Specification adds support for new capabilities of NIEM code lists beyond the basic enumeration representations provided by XML and JSON schema. Key features include the definition of codes in CSV or Genericode files, dynamic code lists via run-time binding, and multi-column code table support.
This example shows different ways to define and represent country codes in NIEM - via free text, XML schema enumerations, and CSV codes via the Code Lists Specification.
A list of known tools and resources available for Genericode.
The NIEM High-Level Version Architecture (HLVA) Specification identifies the processes, artifacts, and responsibilities required to produce new releases of the NIEM model. It also establishes a regular release cycle for predictable and manageable NIEM updates.
NIEM tools provide support for searching and exploring NIEM content and developing NIEM domains and exchanges.
The Schema Subset Generation Tool (SSGT) enables users to search and view the content of the NIEM model, and build XML Schema subsets for use in exchanges.
The Conformance Testing Assistant (ConTesA) enables users to test NIEM XML schemas against the automated rules from the NIEM Naming and Design Rules (NDR).
Movement provides a user-friendly interface and smarter search results for the latest NIEM release. Movement is also open source so the community who inspired its creation can contribute to it.
User guide explaining how to use Movement to search the current NIEM release and build partial NIEM JSON subsets.
The current status of Movement's support of NIEM JSON subsets.
The Migration Tool enables you to upgrade a NIEM XML Schema subset generated by the SSGT to the next release.
The Oxygen XML Editor is a commercial multi-platform XML editor. NIEM provides some additional information and resources for this tool that may assist with domain and IEPD schema development and conformance testing.
Use Oxygen to test a XML schema for NDR conformance.
NIEM XML follows a regular, well-defined syntax. Snippets can be used to quickly and consistently fill in standard syntax, leaving users to fill in the blank or partially-filled in values for fields like name and definition.
Use XML catalog files in Oxygen to specify or override schema file locations.
XMLSpy is a proprietary XML editor and integrated development environment developed by Altova. NIEM provides some additional information for this tool that may assist with domain and IEPD schema development and testing.
Use XML catalog files in XMLSpy to specify or override schema file locations.
How to design a Community of Interest
An easy introduction to the purpose of NIEM, the reasons to use NIEM with JSON data, and the developer knowledge needed to put NIEM JSON into practice.
This tutorial walks the reader through a small example of implementing an information exchange using NIEM-JSON. It begins with a small set of data requirements, constructs a NIEM information exchange model, expresses data for that model as JSON, then constructs a JSON schema for that data.
Provides normative and non-normative guidance on how NIEM and JSON are used, including lots of examples.
NIEM community activities
A dedicated group that supports information sharing and promotes interoperability between mission-based organizations engaged in activities such as homeland security, national defense, border management, immigration benefits, and global law enforcement through the joint development and alignment of Extensible Markup Language (XML) Biometric Standards.
Sample Biometrics XML schema and instances
There are approximately 24 federal agencies that manage grants ranging from health to disasters to education and many other issue areas. A team within the NIEM community is working to identify the common terms, standardize them, and harmonize/unify the grants management systems.
The NIEM Health Community's primary objective is to identify ways to use existing health IT standards to meet the needs of the NIEM community, all while providing education and awareness about the specific requirements for protecting sensitive health data.
Future of NIEM Health COI
Need for Health IT in Disaster Response; Patient Unified Lookup System for Emergencies (PULSE)
NIEM in Canada; Information Exchange Framework Applied to Structured Data
General Update; Protecting Health Information
Health IT, NIEM Health Recap, and Status Update
FHA, FHIM, and NIEM alignment
NIEM Health 101 provides a brief overview of the current health information technology (IT) landscape, related reference exchange and terminology standards, the NIEM Health challenges, and the Federal Health Information Model (FHIM).
NIEM Health 102 provides a brief overview of the security and privacy of protected healthcare information (PHI).
NIEM Health 201 demonstrates how to use health IT standard information models to map NIEM Health use case requirements to NIEM elements and health information exchange standards elements.
The NIEM Health Elements Inventory is a tentative inventory of healthcare elements and types defined across the NIEM domains. The goal of this exercise is to determine what healthcare-related elements have already been defined across the NIEM Domains, compare those elements for completeness and standards compliance with ONC USCDI and health industry standards, and identify gaps that may need to be filled by NIEM Health definitions.
The MilOps Domain provides a catalogue of data components necessary to support improved data interoperability between DOD and mission partners for operations.
A dedicated group to advance information sharing at the state, local, tribal, and territorial level to help protect, support, and respond to community needs.
There is a growing need for information exchanges to include geospatial elements and capabilities—NIEM provides this functionality.
Geo4NIEM Part 1 (2013) was a collaborative, hands-on rapid prototype development and testing initiative in accordance with the Open Geospatial Consortium (OGC)'s Interoperability Program. The partnership included NGA, Department of Defense (DoD), Defense Information Systems Agency (DISA), U.S. Geological Survey (USGS), the Army Geospatial Center and numerous participants and supporters from the public and private sector.
Geo4NIEM Part 2 (2015) was one of four threads in OGC’s Testbed 11—a scenario-based test and demonstration of Geo4NIEM work. It focused on enhancing NIEM’s geospatial exchange capabilities to include Intelligence Community (IC) data encoding specifications, along with OASIS standards to enable granular data object level access authorization and/or denial aligned to OCG web services.
Information and resources for each NIEM release.
An overview of the draft NIEM 5.2 release, currently under development.
An overview of the NIEM 5.1 release.
An overview of the NIEM 5.0 release.
An overview of the NIEM 4.2 release.
An overview of the NIEM 4.1 release.
An overview of the NIEM 4.0 release.
An overview of the NIEM 3.2 release.
An overview of the NIEM 3.1 release.
An overview of the NIEM 3.0 release.
An overview of the NIEM 2.1 release.
An overview of the NIEM 2.0 release.
An overview of the NIEM 1.0 release.
The following is a timeline that shows when new domains were added to NIEM or underwent significant changes.
Summary and detailed counts of properties, types, and codes across NIEM releases.