National Information Exchange Model (NIEM)

NIEM ExchangesReal-Life Examples

September 7, 2006

Tom O’Reilly

Department of Justice

2

Agenda

• State of information sharing

• Where does NIEM fit?

• Relating NIEM to other information sharing mandates and initiatives

• Information exchange life cycle

• Business scenario development

• NIEM pilot panel discussion

• Questions and discussion

3

State of Information Sharing

• As systems exchange information, a service-oriented architecture (SOA) will emerge. Without a framework for reuse, XML stovepipes will be created

• To effectively exchange information, there must be a common semantic understanding of data among participants, and the data must be formatted in a consistent manner

4

Where Does NIEM Fit?

• NIEM is a set of standards for information exchange– The model defines a way of describing information so disparate

systems can exchange it effectively and consistently– It is system-agnostic, so existing IT investments can be leveraged

• NIEM provides the structure and framework for managing and exchanging data elements in a multidomain environment

• Governance processes allow communities to manage their data elements and leverage existing standards, while staying within the model

• Communities and stakeholders can reuse data components from NIEM Universal, Common, and other domains to accelerate development

5

Relating NIEM to Other Information Sharing Mandates and Initiatives

• Homeland Security Presidential Directive (HSPD-5)

• Homeland Security Act 2002

• Intelligence Reform and Terrorism Prevention Act—2004

• Executive Order 13388—Guidelines and Requirements for the Information Sharing Environment (ISE)—2005

• Law Enforcement Information Sharing Program (LEISP)

6

Information Exchange Life Cycle

7

What Are Business Scenarios?

• Describes the business context of events, incidents, or circumstances in which information must be exchanged

• Identifies critical operational points at which information must be shared

• Depicts current information exchange practices among involved parties, thereby identifying gaps, impediments, and other flaws in business processes and data exchange

• Used to characterize potential future environments that envision broader and more expansive information sharing, as well as changes in business practice

8

Scenario Description

The EOC dispatches police, fire units, and emergency medical personnel. The cause of the damage and the fire, as well as the extent of the damage and scope of the emergency, takes time to establish. First responders arriving on scene begin reporting back to the EOC on the nature and scope of the damage, which is extensive and may well result in a catastrophic collapse of the entire building and potentially extensive damage to surrounding buildings. Initial on-scene units find the aftermath of a significant explosion with several ongoing fires and many “walking wounded” wandering throughout the incident scene.

Identify Scenario-Based

Business Requirements

The 911 Emergency Operations Center (EOC) of a midsized urban jurisdiction begins receiving telephone calls from residents regarding what is variously described as a fire, an explosion, and a partial building collapse of a 25-story building in city center. The calls quickly escalate in number and urgency and are received from residents of the affected office building, local residents of other nearby buildings, and cellular telephone calls from pedestrians and passing motorists.

9

Scenario Description (continued)

Police and fire units initiate a command post across the street from the incident location. Police units establish a critical perimeter for public safety entry only and begin initiation of a secondary perimeter using Geographic Information Systems (GIS) mapping. Emergency Medical Services (EMS) set up an initial triage contiguous to the police and fire command post. Initial injured are assessed, and information is forwarded to area hospitals via devices that are tracking hospital capacities, services available, and patient transports.

Identify Scenario-Based

Business Requirements

Real-time video feeds are transmitted from the scene to the command post. Personnel location technology is in use providing 2D/3D location and biotelemetry of fire and police personnel to their command staffs, as well as monitoring of immediate air quality in proximity to the explosion site. Upon completion of the first search, the scene is declared unsafe and messages are sent to all on-scene personnel to remain outside of the critical perimeter until the scene is cleared by the bomb squad. The media is kept informed of progress, as appropriate.

10

Identify Information Exchanges

Exchange 1: The EOC dispatches police, fire units, and emergency medical personnel

The scenario describes in narrative form an operational situation, business context, legislative, judicial or executive mandate, or other circumstance which must be addressed. From this scenario, individual, discrete information exchanges are identified for subsequent analysis.

Identify Scenario-Based

Business Requirements

11

Identify Information Exchanges (continued)

Exchange 2: First responders arriving on scene begin reporting back to the EOC on the nature and scope of the damage

Identify Scenario-Based

Business Requirements

12

Identify Information Exchanges (continued)

Exchange 3: Initial injured are assessed, and information is forwarded to area hospitals via devices that are tracking hospital capacities, services available, and patient transports

Identify Scenario-Based

Business Requirements

13

Analyze Requirements for Business Exchange

Detailed information identifying triggering events, agencies involved, conditions surrounding the exchange, and documenting the actual data exchanged is captured for analysis and mapping

This detailed analysis of all dimensions of the information exchange can then be analyzed, graphically displayed, and mapped to NIEM to discover and reuse IEPDs and Universal and Common components

1

14

Map and Model Exchanges

Begin by determining whether an existing IEPD either fully or closely meets your information exchange requirements

• Search and discover existing IEPDs by business context

• Compare information exchange requirements to IEPDs found

NIEMIEPD

NIEMIEPD

NIEMIEPD

OperationalExchange

Conduct gap analysis on the data components you will need to build this exchange. Use tools (e.g., CMT) to document results

• Identify each data component that maps to a NIEM component and each that does not

• For those that do not exist, create new components using the NIEM NDR

• For those that do no map well, document the need for extensions or refinements to existing NIEM components

Decide if the new components created should be submitted for integration into NIEM

OperationalExchange

NIEMComponents

NEIMComponent

NewComponent

Extend

2

15

NIEM Pilots Based on Scenarios

• Content Contributor Pilots– DHS Immigration and Customs

Enforcement• ICE Enterprise Data Model mapping to

NIEM

– DHS Customs and Border Protection• United Nations Trade Data Elements

Directory (UNTDED)

– DHS Emergency Management• Adding Disaster Management,

Resource Message contents

– Geospatial Community of Interest• Adding Geospatial contents

– DHS Team 5 Pilot• People Screening data elements from

five DHS components

– DHS Infrastructure Protection (NADB)• Adding infrastructure protection

contents

• Early Adopter Pilots– Intelligence Community Watchlist

Message Pilot• Terrorist Watchlist Person Data

Exchange Standard (TWPDES) Working group, OCIO Watchlist and NCTC actively participating

– National Capital Region Data Exchange Hub Pilot

• Virginia, DC, and Maryland representatives leading the pilot

• In partnership with the Disaster Management eGov initiative

• Initial target: First responder resource request messages

– OCIO ITEP Pilots (kickoff in August 2006)

• Data model validation using semantic web techniques

• JIEM Tool for business stakeholder facilitation

Intelligence

Anthony Hoang

Title

Agency

R-DExRegional Data Exchange

Bard LaabsTechnology Manager

Automated Regional Justice Information System

18

Introduction to ARJIS

• Automated Regional Justice Information System (ARJIS)– San Diego’s Regional Law Enforcement

Consortium– 70+ local, state, and federal member

agencies – 11,000+ users– 3,000 terminals on secure intranet

(ARJISNet)– Strong governance for data sharing– Cost sharing benefits entire region

19

Introduction to the R-DEx Project

• Regional Data Exchange (R-DEx)– Federally driven

• FBI• U.S. Marshals• U.S. Bureau of Prisons• ATF• DEA

– Regional interagency data sharing– ARJIS partnership with FBI

• Exchange and share data with non-federal agencies

• Allows searching, analyzing, and mapping of data from local and remote sources

• Integration with existing applications (LINX, CopLink)

20

Project Drivers

• Law Enforcement Information Sharing Program (LEISP) – This strategy is the result of a

collaborative process involving senior leadership from DOJ component agencies and representatives from across the national law enforcement community

– LEISP is DOJ’s strategy for sharing DOJ data—from all its components—with the Information Sharing Environment (ISE) mandated by the Intelligence Reform and Terrorism Prevention Act of 2004

21

RDEx Project Goals and Architecture

• Open standards• Common vocabulary• Exchange standards• Flexible• Extensible • Multiagency • Analytical tool• Link analysis• Mapping

• R-DEx—federally mandated analytical data sharing

• 1st Generation—unstructured searching

• 2nd Generation—NIEM-based, structured searching (currently in development)

LEXS – SRLEXS – SRSearch and RetrievalSearch and Retrieval

Federal Document IngestionFederal Document Ingestion

LEXS – PDLEXS – PDPublish and DiscoveryPublish and Discovery

R-DEx ApplicationR-DEx Application

22

LEISP Exchange Specifications

• R-DEx is based on LEISP Exchange Specifications (LEXS) – Developed with NIEM v0.3– Standardized entities

• LEXS is a family of NIEM IEPDs– Publish and Discovery (LEXS-PD)– Search and Retrieval (LEXS-SR)

• LEXS benefits for data providers– Reduce custom data extracts– Reduce development efforts– Cross-domain

• LEXS benefits for data consumers– Standard interfaces for new sources

23

Issues

• The LEXS specification crosses several domains – Local law enforcement– Federal law enforcement– Intelligence– Corrections

• Conflicts and differences among domains– Activity-based vs. document-based– Metadata vs. actual data– Some consider vehicles another “entity,” some property– Corrections details unlike other law enforcement data– Explosives and drug information were different between the domains

• Different users—different needs—one standard– Local—street cops/investigators, data searching– Federal—analysts, analysis/mapping of data

• Choices when mapping fields– Using existing NIEM fields– Extending NIEM with new fields– Placing data in generic attributes or package metadata

24

The Data Model

• There are five entities in the LEXS model– Person

– Location

– Organization

– Telephone number

– Property

• NIEM association objects relate to LEXS entities• LEXS groups entities into logical records,

defined by the source system– Incident data

– Document data

– Inmate record

• Business domains are abstracted as “data items” rather than by introducing another distinct structure to represent them

25

Process

• LEXS development– LEXS leverages and reuses work from LEISP and NIEM. This specification defines the first use of NIEM as part

of LEISP• Mapping LEXS entities and attributes to NIEM

– Takes logical model into XML and includes concepts of objects, properties, roles, and associations

Line # LEXS Logical Entity / Attribute NIEM Mapping

1 Person c: Person (c:PersonType)

2 1 Name 1 u:PersonName (u:PersonNameType)

3 1 Full Name 1 u:PersonFullName (u:PersonNameTextType)

4 2 First 2 u:PersonGivenName (u:PersonNameTextType)

5 3 Middle 3 u:PersonMiddleName (u:PersonNameTextType)

6 4 Last 4 u:PersonSurName (u:PersonNameTextType)

7 2 Alias 2 c:new:PersonAlias (c:newPersonAliasType)

8 1 Alias Name c:PersonAlternateName (u:PersonNameType)

9 1 Full Name 1 u:PersonFullName (u:PersonNameTextType)

10 2 First 2 u:PersonGivenName (u:PersonNameTextType)

11 3 Middle 3 U:PersonMiddleName (u:PersonNameTextType)

12 4 Last 4 U:PersonSurName (u:PersonNameTextType)

• Within the 5 main entity groups (person, location, organization, telephone number, and property)—over 280 entities and attributes were mapped from LEXS to NIEM

26

Adding NIEM to R-DEx

• R-DEx– Existing project– Unstructured document-searching capability– Second phase to add structured content searching– LEXS standard (based on NIEM) developed by DOJ– Two IEPDs generated

• LEXS-PD: Publish and Discovery– Used to import data into R-DEx from federal agencies

• LEXS-SR: Search and Retrieval– Used to allow searching by remote systems and of remote

systems

27

Adding NIEM to ARJIS/CopLink

• ARJIS– Original R-DEx interface internally developed, stand alone web application

– Allowed searching R-DEx using the unstructured methods

– Did not have any capabilities beyond a text search

• LEXS-SR enabled additional analysis and mapping capabilities• ARJIS was using the commercial application CopLink for officer

analysis and mapping– ARJIS approached CopLink to develop R-DEx interface

– Incorporate R-DEx into base product

• CopLink wrote interface LEXS-SR-compliant interface to R-DEx• Will allow other agencies using CopLink to connect with R-DEx with

greatly reduced effort

28

Different Views, Different ToolsSame Data

ARJIS CopLinkR-DEx

29

Scenario

• Building collapse– Local and federal law enforcement collaborate; determine cause was explosive

device– Witnesses saw two people leaving the area just before the explosion

• Male, 5-10, blond hair and Female, 5-7, brown hair

• R-DEx is used to search– Field interviews and citations in the area of the crime for the last two weeks

• Local data• Find several candidates which match the descriptions

– Candidates are searched for any connection to explosives• ATF data• Find one man (John Harris) who was contacted in the area with a connection to

explosives

– All of the associates of John Harris are found• All data• Female matching the description is found• Associations between male and female are found with members of terrorist group

30

Life Cycle

• US DOJ led the effort to develop the LEXS specification

• R-DEx is currently at Step #5

• Next revision of LEXS specification will start again at Step #1

31

The Future

• R-DEx and ARJIS are currently in testing– Expected release 9/20

• Next generation enhancements– Add “roles” to schema – Add attributes to represent additional details for entities– Add ability to search by date range

• Additional applications R-DEx enabled– LINX– Other CopLink sites– Possible to connect CopLink to LINX directly, using

LEXS protocol

Emergency Management

Tim GrapesEvolution Technologies, Inc.

Department of Homeland Security (DHS)Science and Technology (S&T) Directorate Office for Interoperability and Compatibility

(OIC)

33

Background—OIC Organization Chart

• OIC’s purpose is to strengthen and integrate interoperability and compatibility efforts to improve local, tribal, state, and federal emergency responders’ preparedness and response

Science & Technology (S&T) Directorate

Office for Interoperability and Compatibility (OIC)

Testing and EvaluationDisaster Management (DM)

SAFECOM

Communications Equipment Training

34

DM works in partnership with local, state, tribal, and federal partners to develop tools and messaging standards that help emergency responders seamlessly exchange information vital to effective incident management, response, and recovery

Federal Interoperability Initiatives

35

Background

• Common Alerting Protocol (CAP)—OASIS standard, October 2005• Provides standard all-hazard emergency alerts, notifications, and public

warnings which can be disseminated simultaneously over many different warning systems (e.g., computer systems, wireless, alarms, TV, radio)

• Emergency Data Exchange Language (EDXL)• EDXL Distribution Element (DE)—OASIS standard, April 2006• Provides flexible message distribution framework for emergency information

systems data sharing. Messages may be distributed by specific recipients, by a geographic area, or by other codes such as agency type (police, fire, etc.)

• EDXL Hospital AVailability Exchange (HAVE)—OASIS public comment phase• Provides standard exchange of hospital status, capacity, and resource

availability among medical, health, and emergency organizations• EDXL Resource Messaging (RM)—OASIS submission, January 2006• Approximately 20 standards for exchange of resource information (persons

and/or things) needed to support incident preparedness, response, management and recovery, and planned events

36Lowest

Highest

Us

ag

e

Pri

ori

ty

Lowest

Highest

Local Agency-Specific

Regional Interagency &

Interdisciplinary

State and

Federal

• SAFECOM’s executive committee and emergency response council facilitate the input of emergency responders, policymakers, and leaders

• DM’s practitioner steering group ensures that initiatives and tools effectively meet practitioners’ information-sharing priorities and requirements

Practitioner-Driven Approach

• SAFECOM and DM both advocate a unique, “bottom-up” approach. The programs’ practitioner-driven governance structures benefit from the critical input of the emergency response community and from local, state, tribal, and federal policymakers and leaders

37

DM Standards Development—Key Players

• Internal– DM practitioner groups

• Practitioner Steering Group (PSG)• Standards Working Group (SWG)

– Emergency management– Fire– 9-1-1, dispatch – Transportation– Emergency medical services– Public health– Federal emergency agencies– Supporting vendor

communities

• External– Global Justice Extensible Data Model

(GJXDM)– National Incident Management

Systems (NIMS)– Organization for the Advancement of

Structured Information Systems (OASIS)

– National Information Exchange Model (NIEM)

– Emergency Interoperability Consortium (EIC)

– Global Justice/Bureau of Justice Assistance (BJA)

– National Capital Region (NCR)– Federal Emergency Management

Agency (FEMA) Mutual Aid

38

SWG drafts technical specifications and use

cases

PSG priortizes and drafts specific requirements

PSG and PMO review, modify and/

or endorse SWG findings

SWG provides a formal draft standards

document to the PSG and PMO

The PSG reviews, endorses, and submits the

formal draft standards document to the

appropriate standards organization upon PMO

approval

SWG provides PSG and PMO

with any change recommendations

from pilots

Standards organization submits standard to vote

for approval by membership

SWG researches other efforts and makes

recommendations to PSG and PMO

Technical reviews and pilot demonstrations

are conducted to validate the standard

DM Standards Development—Process

1. Practitioner Steering Group (PSG)2. Standards Working Group (SWG)—iterative methodology consistent with

Information Exchange Package Description (IEPD) methodology3. Scenarios/“use examples” subcommittees4. Draft specification—message definition consistent with IEPD5. EIC/vendor community6. Submission to NIEM and Public Standards Organization (OASIS)

39

National Capital Region (NCR) Data Exchange Hub

• Provide a real-time interactive system designed to strengthen the flow of information both within and between Emergency Support Functions (ESFs) within the NCR’s 19 jurisdictions

• Provide a collaborative communications environment, through which member jurisdictions collect and disseminate information between themselves and with federal and state agencies involved in securing the NCR

• Utilize and test open standards-based approach (GJXDM, NIEM, EDXL)

• Build a resource-typing Web service-based search for emergency resources in the NCR

• Provide a reference implementation and training program

40

NCR Data Exchange Hub Demonstration—Project Focus

• Participants—cross section of first responders (law enforcement officers, fire fighters, and emergency managers) and their technical support staff

• Exchanges—standardized information exchange of resource and inventory information between the primary Emergency Operation Centers (EOCs) supporting the 19 jurisdictions of the NCR– What resources are available from other jurisdictions?

– Consolidated picture of NCR resources

– Utilized draft Resource Messaging (RM) standard components of NIEM 0.2 and the FEMA mutual aid resource typing structure

41

NCR Exchange Development Life Cycle (EDLC)

WS Building

WS Building

WS Publish,Bind, Find

WS Publish,Bind, Find

REQUIREMENTS DESIGN IMPLEMENTDEVELOP

NCR Interoperability Program

.Net WSDL.Net

WSDLJava WSDLJava WSDL

WS Security Policies

WS Security Policies

WSDL UDDI

Registration

WSDL UDDI

Registration

Messages on ESB

Messages on ESB

EXCHANGE DEVELOPMENT LIFE CYCLEEXCHANGE DEVELOPMENT LIFE CYCLE

ARTIFACTSARTIFACTS

JIEMSite DBJIEM

Site DB CharterCharter

Work-GroupWork-Group

ProjectInceptionProject

Inception

IDEIDE RegistriesRegistriesPolicy ManagerPolicy ManagerESBESB

DomainModelingDomain

ModelingGJXDMMappingGJXDMMapping

SchemaBuildingSchemaBuilding PackagingPackaging

DomainModel

DomainModel

MappingArtifact

MappingArtifact

XMLSchema

XMLSchema

MethodSignature

From JIEM

MethodSignature

From JIEM

JIEMReference

Model

JIEMReference

Model

JIEMTool

JIEMTool

Modeling/Diagramming

Tools

Modeling/Diagramming

Tools

LocalRequirements

LocalRequirements

GJXDMSearch

Tool

GJXDMSearch

Tool

JIEMTool

JIEMTool

SubsetSchema

Tool

SubsetSchema

Tool

XMLEditorXMLEditor TOOLSTOOLS

GOVERNANCE PROCESS AT THE OPERATIONAL LEVEL TO BE DEFINED IN GOVERNANCE PROCESS AT THE OPERATIONAL LEVEL TO BE DEFINED IN FY05 FY05

AND INSERTED AT APPROPRIATE STAGES IN THE DEVELOPMENT LIFE AND INSERTED AT APPROPRIATE STAGES IN THE DEVELOPMENT LIFE CYCLECYCLE

Artifacts stored in web-based IEPD

42

NCR Exchange Development Life Cycle (EDLC)

43

NCR Data Exchange Hub Demonstration Project

44

NCR Data Exchange Hub Demonstration Project Resources

• Resource Typing IEPD – http://www.ncrnet.us/DEH/IEPD/

• NCR Development Toolkit – http://www.ncrnet.us/DEH/toolkit/index.htm

• DEMO – http://www.ncrnet.us:8080/frri/pages/main.jsp

45

NIEM Benefits

• One-stop shop and proven methodology to implement practitioner-driven information sharing standards

• Standardize and strengthen the flow of information both within and between Emergency Support Functions (ESFs) within the NCR

• Position for broader information sharing outside of NCR• Facilitates information sharing regardless of local system

differences or Web services technology applied• Facilitates draft standard testing and feedback to improve

final standard support for local requirements• Simplification of grants compliance

46

Program:Chip Hines: chip.hines@dhs.govBill Kalin: bill.kalin@associates.dhs.gov

DM Messaging Standards Initiative:Tim Grapes: tgrapes@evotechinc.comLee Tincher: ltincher@evotechinc.com

Contacts

47

Questions and Discussion

• For more information, visit the NIEM Web site (http://www.niem.gov)

• Contact NIEM by e-mail at information@niem.gov