National Information Exchange Model (NIEM) NIEM Exchanges Real-Life Examples September 7, 2006

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

9. 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 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 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

11. 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

12. 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

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

14. 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 Operational Exchange NIEM IEPD NIEM IEPD NIEM IEPD • 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 Components Extend New Component

15. 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 NIEM Pilots Based on Scenarios

16. Intelligence Anthony Hoang Title Agency

17. R-DExRegional Data Exchange Bard Laabs Technology 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. Federal Document Ingestion LEXS – PDPublish and Discovery RDEx Project Goals and Architecture • R-DEx—federally mandated analytical data sharing • 1st Generation—unstructured searching • 2nd 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 LEXS – SRSearch and Retrieval

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 • 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 R-DEx ARJIS CopLink

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

32. Emergency Management Tim Grapes Evolution 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) Communications Equipment Training SAFECOM Testing and Evaluation Disaster Management (DM)

34. 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

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

36. Highest Highest Local Agency-Specific Usage Regional Interagency & Interdisciplinary Priority State and Federal Lowest Lowest 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 • 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

37. 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 DM Standards Development—Key Players

38. 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) DM Standards Development—Process

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

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. Contacts Program: Chip Hines: chip.hines@dhs.govBill Kalin: bill.kalin@associates.dhs.gov DM Messaging Standards Initiative: Tim Grapes: tgrapes@evotechinc.com Lee Tincher: ltincher@evotechinc.com

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