National Information Exchange Model NIEM NIEM Exchanges Real-Life

National Information Exchange Model (NIEM) NIEM Exchanges Real-Life Examples September 7, 2006 Tom O’Reilly Department of Justice

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 2

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 3

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 4

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) 5

Information Exchange Life Cycle 6

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 7

Identify Scenario-Based Business Requirements Scenario Description 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. 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. 8

Identify Scenario-Based Business Requirements 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. Real-time video feeds are transmitted from the scene to the command post. Personnel location technology is in use providing 2 D/3 D 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. 9

Identify Scenario-Based Business Requirements Identify Information Exchanges 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. Exchange 1: The EOC dispatches police, fire units, and emergency medical personnel 10

Identify Scenario-Based Business Requirements 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 11

Identify Scenario-Based Business Requirements 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 12

1 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 13

Map and Model Exchanges 2 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 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 Operational Exchange NEIM Component NIEM IEPD Extend Operational Exchange NIEM Components New Component 14

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 e. Gov 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 15

Intelligence Anthony Hoang Title Agency

Bard Laabs R-DEx Regional Data Exchange Technology Manager Automated Regional Justice Information System

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 18

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, Cop. Link) 19

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 20

RDEx Project Goals and Architecture • R-DEx—federally mandated analytical data sharing • 1 st Generation—unstructured searching • 2 nd Generation—NIEM-based, structured searching (currently in development) • Open standards • Common vocabulary • Exchange standards • Flexible • Extensible • Multiagency • Analytical tool • Link analysis • Mapping R-DEx Application Federal Document Ingestion LEXS – SR Search and Retrieval LEXS – PD Publish and Discovery 21

LEISP Exchange Specifications • R-DEx is based on LEISP Exchange Specifications (LEXS) – Developed with NIEM v 0. 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 22

Issues • The LEXS specification crosses several domains – – • Conflicts and differences among domains – – – • Local law enforcement Federal law enforcement Intelligence Corrections 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 23

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 24

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 # 1 2 LEXS Logical Entity / Attribute Person 1 NIEM Mapping c: Person (c: Person. Type) Name 1 u: Person. Name (u: Person. Name. Type) 3 1 Full Name 1 u: Person. Full. Name (u: Person. Name. Text. Type) 4 2 First 2 u: Person. Given. Name (u: Person. Name. Text. Type) 5 3 Middle 3 u: Person. Middle. Name (u: Person. Name. Text. Type) 6 4 Last 4 u: Person. Sur. Name (u: Person. Name. Text. Type) 7 8 2 Alias 2 1 Alias Name c: new: Person. Alias (c: new. Person. Alias. Type) c: Person. Alternate. Name (u: Person. Name. Type) 9 Full Name 1 u: Person. Full. Name (u: Person. Name. Text. Type) 10 2 First 2 u: Person. Given. Name (u: Person. Name. Text. Type) 11 3 Middle 3 U: Person. Middle. Name (u: Person. Name. Text. Type) 12 • 1 4 Last 4 U: Person. Sur. Name (u: Person. Name. Text. Type) Within the 5 main entity groups (person, location, organization, telephone number, and property)—over 280 entities and attributes were mapped from LEXS to NIEM 25

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 26

Adding NIEM to ARJIS/Cop. Link • 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 Cop. Link for officer analysis and mapping – ARJIS approached Cop. Link to develop R-DEx interface – Incorporate R-DEx into base product • Cop. Link wrote interface LEXS-SR-compliant interface to R-DEx • Will allow other agencies using Cop. Link to connect with R-DEx with greatly reduced effort 27

Different Views, Different Tools Same Data R-DEx ARJIS Cop. Link 28

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 29

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 30

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 Cop. Link sites – Possible to connect Cop. Link to LINX directly, using LEXS protocol 31

Emergency Management Tim Grapes Evolution Technologies, Inc. Department of Homeland Security (DHS) Science and Technology (S&T) Directorate Office for Interoperability and Compatibility (OIC)

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) Communications SAFECOM Disaster Management (DM) Equipment Training Testing and Evaluation 33

Federal Interoperability Initiatives 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 34

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 35

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 Highest Highes t • SAFECOM’s executive committee and emergency response council facilitate the input of emergency responders, policymakers, and leaders Regional Interagency & Interdisciplinary Priority Usage • DM’s practitioner steering group ensures that initiatives and tools effectively meet practitioners’ information-sharing priorities and requirements Local Agency. Specific State and Federal Lowest 36

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 37

DM Standards Development— Process 1. 2. 3. 4. 5. 6. Practitioner Steering Group (PSG) Standards Working Group (SWG)—iterative methodology consistent with Information Exchange Package Description (IEPD) methodology Scenarios/“use examples” subcommittees Draft specification—message definition consistent with IEPD EIC/vendor community Submission to NIEM and Public Standards Organization (OASIS) 38

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 39

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 40

NCR Exchange Development Life Cycle (EDLC) DESIGN REQUIREMENTS DEVELOP IMPLEMENT GOVERNANCE PROCESS AT THE OPERATIONAL LEVEL TO BE DEFINED IN FY 05 AND INSERTED AT APPROPRIATE STAGES IN THE DEVELOPMENT LIFE CYCLE EXCHANGE DEVELOPMENT LIFE CYCLE JIEM Site DB Charter Domain Model Work. Group Project Inception JIEM Reference Model Method Signature From JIEM Tool Modeling/ Diagramming Tools WS Security Policies Mapping Artifact XML Schema ARTIFACTS GJXDM Mapping Domain Modeling Schema Building Packaging GJXDM Search Tool JIEM Tool Subset Schema Tool XML Editor Artifacts stored in web-based IEPD TOOLS . Net WSDL Java WSDL UDDI Registration WS Building IDE Messages on ESB WS Publish, Bind, Find ESB Policy Manager Registries Local Requirements NCR Interoperability Program 41

NCR Exchange Development Life Cycle (EDLC) 42

NCR Data Exchange Hub Demonstration Project 43

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 44

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 45

Contacts Program: Chip Hines: chip. hines@dhs. gov Bill Kalin: bill. kalin@associates. dhs. gov DM Messaging Standards Initiative: Tim Grapes: tgrapes@evotechinc. com Lee Tincher: ltincher@evotechinc. com 46

Questions and Discussion • For more information, visit the NIEM Web site (http: //www. niem. gov) • Contact NIEM by e-mail at information@niem. gov 47