NIEM and SOA for Mission Critical System

Office of the Program ManagerInformation Sharing Environment

August 2011www.ise.gov

Agenda

• National Information Exchange Model (NIEM) – What is it?

• NIEM and SOA at New York State Police

• Why is this relevant at a Healthcare Conference?

This is Not a Healthcare Case Study, but We Share Similar Problems and Potentially NIEM Might Offer a Solution….

NIEM – What is it?

• An XML-based voluntary consensus standard with a pre-harmonized vocabulary to enable information sharing

• Designed to develop, disseminate and support cross-enterprise information exchange

• Enable mission partners to effectively share critical information in emergency situations, as well as support the day-to-day operational information sharing requirements

• Managed by the DoJ, DHS, HHS, the Global Justice Information Sharing Initiative

The NIEM Framework

NIEM connects communities of people, and provides a foundation for seamless information exchange between federal, state, local, and tribal agencies.

Support Framework

Tools for Development and Discovery

Established Training Program

Implementation Support

Community

Self-Managing Domain Stewards

Formal Governance Processes

Online Repositories

Mission-Oriented Domains

Technical Framework

Data Model

XML Design Rules

Development Methodology

Predefined Deliverables (IEPD)

Help Desk & Knowledge Center

NIEM – Historic Perspective

• 2000 – GJXDD - Global Justice XML Data Dictionary

• 2003 – GJXDM – Global Justice XML Data Model

• 2005 – NIEM program is established

• 2006 – NIEM 1.0 is released

• 2011 – Current version is 2.1

• 2013 – Anticipated release of NIEM 3.0

NIEM Model Architecture

NIEM Core consists of data elements that

are commonly understood across

domains

NIEM Domains include mission

specific data that is managed through

independent stewards

Future Domains are added to NIEM as

necessary based on an established need

What is an IEPD?

An Information Exchange Package Documentation (IEPD) is a collection of artifacts that describe the construction

and content of an information exchange

A. Developed to provide the business, functional, and technical details of the information exchange through predefined artifacts

B. Created with a core set of artifacts in a prescribed format and organizational structure to allow for consistency

C. Designed to be shared and reused in the development of new information exchanges through publication in IEPD repositories

The IEPD Lifecycle

The IEPD

Lifecycle

Plan the project, establish the process, and identify information exchange business requirements

Selected information exchange is further elaborated to understand and document the business context and data requirements

Associate local objects with types and elements in NIEM. This process is called mapping an exchange content model to NIEM

Create a set of exchange-specific NIEM conformant XML schemas that implement the data model created for the exchange

Prepare and package all related files for this IEPD into a single self‐contained, self-documented, portable archive file

Publish IEPD for search, discovery, and reuse

Scenario Planning

Analyze Requirements

Map & Model

Build & Validate

Assemble & Document

Publish & Implement

Scope of IEPDs

IEPDs contain design specifications for an information exchange but may not include supplementary information such as implementation decisions

� Include the XML schemas that define the XML message structure

� Contain standardized artifacts that document an information exchange

� Have a defined development methodology (IEPD Lifecycle)

� Ease the documentation process for reuse

� Specify how exchange data is physically transferred between entities

� Describe an interface or Interface Control Document (ICD)

� Specify any technical information outside of the message structure

IEPDs do IEPDs do not

Future UML Profile for NIEM

• Standardized model representing NIEM packages

• Build upon the scope of the existing profile to include support for MPD development

• Support “model-driven” MPD development

• The profile will reflect NIEM architectural concepts and restrictions as set forth in the NIEM Naming and Design Rules (NDR) v1.3 and Model Package Description Specification (i.e. we don’t want to accommodate all of XML schema, only what is allowed by the NDR)

• End Goal: A developer (using supporting tools) should be able to generate an equivalent conformant MPD from any UML model that applies the envisioned UML profile properly. Conversely, a developer should be able to create an equivalent profiled UML model from a conformant MPD.

New York Statewide Police Information Network (NYSPIN)NIEM and SOA at New York State Police

Case Study

Scenario….

We have all seen someone getting pulled over by a cop, right?

Here's what happens –

• The officer gathers the driver’s license/registration information

• Driver and passengers stay in the car for what feels like an eternity

• Officer often comes back after a few minutes, and

– Lets the driver off with a warning, or

– Gives the driver a ticket, or

– Gives the driver a ticket and asks him/her to appear in court, or

– Just arrests the driver (and maybe the passengers)

Here’s what really happens….

• The officer has some combination of the following information:

� Vehicle plates and registration

� Driver’s license

• The officer checks the driver/vehicle information against:

� DMV systems for driver and registration information

� Repositories (hot files) for stolen property (vehicles, boats, snowmobiles, guns, etc.) to see if the vehicle is stolen

� Criminal history and other repositories for Wanted, Missing and unidentified persons, Parole, orders of protection, etc. to see if the driver is wanted

� Other repositories for Lo Jack, sex-offender registries, gang related activities, etc.

• The officer makes an informed decision

What is NYSPIN?

• Each state has one messaging solution --the “SWITCH”

◦ Allows all law enforcement users to connect to remote distributed systems for DMV, Criminal History, Stolen Property, Warrants, etc.

◦ Critical system for crime prevention, law enforcement, and officer safety

◦ Very high transaction volumes

• New York SWITCH is NYSPIN (New York Statewide Police Information Network)

◦ 1100 Enforcer terminals directly connect to this system

◦ About 107 Metro user connections to CAD, RMS, Mobile systems, etc.

◦ About 50,000 users (direct and indirect)

◦ About 1.5 Million messages per day

• Legacy switch used COBOL on a UNISYS mainframe environment, proprietary protocols and interface definition

NY Long -term Justice Information Sharing Vision

“Provide ‘one-stop

information shopping

platform’ for all law

enforcement, justice and correction

entities and users”

Integrated Justice Community: Stakeholders and Partners

In-State Agencies Out-of -State Agencies

• Law Enforcement/Criminal Justice Agencies: – Division of State Police – Division of Criminal Justice Services – Local Police Departments – Sheriffs Departments – Administrative Office of the Courts

• Corrections Agencies: – State Prisons – Sheriffs Department of Corrections – Probation – Parole

• Other Agencies – Division of Homeland Security and

Emergency Services – Department of Motor Vehicles – Division of Tax and Finance

• Federal Bureau of Investigation: – National Crime Information Center

(NCIC) for Hotfiles • The International Justice and Public

Safety Network (NLETS): – 49 State DMV Records – 49 State Rap Sheets – 49 State Criminal History – Lo Jack – National Weather Service – Immigration Services – Canadian Police Information Center

(CPIC) – Interpol

Challenges Faced

• Mission critical system -- stringent requirements around accuracy, performance and high availability

◦ Desire to roll-out the new solution with minimal disruption of services

• Coordination among multiple in-state and National agencies

• Multiple point-to-point connections

• No standard business vocabulary

• Manual (paper-based) processes

• Islands of data often with no unified view of information

• Changes were expensive and time consuming

• Proprietary and legacy protocols and formats

◦ Limited support for the existing legacy infrastructure

Solution – Integrated Justice Portal

NYSPIN scope

Courts

Probation

NYC DOS

Tax and Finance

Attorney General

NY Division of Motor Vehicles

Local LawEnforcements

NY Sheriffs

NY Courts

NY Attorney General

CCH and WarrantsPublic Safety

NYC Department ofSanitation

State Prison ParoleProbation and CorrectionalAlternatives

Tax and Finance

UNYRIC

Regional Intelligence Center

NYDHS

HomelandSecurity

Other Civil Agencies

Civil Agencies

UpgradedInterfacesLegacyInterfaces

Integrated Justice PortalPortal based user interface

SOA Business ServicesMessaging Hub

Web Services and MQ based interfaces

Highlights

• 100% compliance with NYSP architectural requirements for open hardware and software standards; minimal vendor dependency

• SOA solution with end-to-end NIEM conformance

• 85 course-grain & 140 fine-grain services support all functionality

• Transition Strategy supported terminal devices during migration to Portal-based UI and web services-based Metro interfaces

• Not a COTS package -- integrated solution using commercial COTS

• Supports 20,000 internal and 30,000 external users

• 1.6 million messages per day - On average 13 messages per second, 52 messages per second during peak time

19

IJP – Application Architecture

WebSphere Business Integration Message Broker

Integration Bus ( MQ/JMS/WebServices )

Channels and Business

Applications Client Layer

Service Agency / Data

Layer

Integration Services Layer

Business Service Layer

Connector

DTF

Connector

NLETS

Connector

NCIC

Connector

DMV

IBM WebSphere Application Server

Enforcer 2KBrowser

Metros(to Be)

CCH, Hotfiles

XML JMS (Asynchronous)

ODS

Business Services (One per business domain)

Fine Grain Business Services (Reused across coarse grain)

Service Agency Abstraction Layer

Presentation Layer /

Transitional

IBM Websphere Portal

Transitional Websphere Integration message Broker

Web Service

Enterprise Java Beans (Stateless Session Beans)

Com

mon

Servic

es S

cop

e

Business Service Interface Layer

Via Transitional Adapter- Non NIEM Compliant

Synchronous

Transitional Java Wrapper (Message Driven Beans)

Asynchronous

Synchronous NIEM Compliant Web Services

Metros(Legacy)

Transform

ation R

outing, E

nrichment

Notification

Aggregation

Au, A

z

Data V

alidation, Security (A

z)

Correlation

Log, Audit, E

xceptionData Abstraction Layer

WebSphere Business Integration Message Broker

Integration Bus ( MQ/JMS/WebServices )

Channels and Business

Applications Client Layer

Service Agency / Data

Layer

Integration Services Layer

Business Service Layer

Connector

DTF

Connector

NLETS

Connector

NCIC

Connector

DMV

IBM WebSphere Application Server

Enforcer 2KBrowser

Metros(to Be)

CCH, Hotfiles

XML JMS (Asynchronous)

ODS

Business Services (One per business domain)

Fine Grain Business Services (Reused across coarse grain)

Service Agency Abstraction Layer

Presentation Layer /

Transitional

IBM Websphere Portal

Transitional Websphere Integration message Broker

Web Service

Enterprise Java Beans (Stateless Session Beans)

Com

mon

Servic

es S

cop

e

Business Service Interface Layer

Via Transitional Adapter- Non NIEM Compliant

Synchronous

Transitional Java Wrapper (Message Driven Beans)

Asynchronous

Synchronous NIEM Compliant Web Services

Metros(Legacy)

Transform

ation R

outing, E

nrichment

Notification

Aggregation

Au, A

z

Data V

alidation, Security (A

z)

Correlation

Log, Audit, E

xceptionData Abstraction Layer

20

Websphere Application Server

Por

tal C

onta

iner

Por

tlet

Portal Framework

Clie

nt B

usin

ess

Inte

rfac

e

Enforcer and Transitional Adapter

Enf

orce

r

Tra

nsiti

onal

Gat

eway

Tra

nsiti

onal

Bro

ker

Metro

Met

ro

Web

Ser

vice

TA

Mes

sage

Driv

en B

ean

Ent

erpr

ise

Java

Bea

ns(S

tate

less

Ses

sion

Bea

n)

Bus

ines

s S

ervi

ces

(Coa

rse

Gra

in +

Fin

e G

rain

)

Ser

vice

Age

ncy

Acc

ess

Rou

ter

Tra

nsfo

rmat

ion

Ada

pter

Ser

vice

Age

ncy

Websphere Business

Integrator

Plain Old Java Objects

WBI Components

WAS Components

External Resource

Reusable Services Framework

Remote Queue

Local Queue

Legend

Por

tlet

NIEM XML

Websphere Application Server

Por

tal C

onta

iner

Por

tlet

Portal Framework

Clie

nt B

usin

ess

Inte

rfac

e

Enforcer and Transitional Adapter

Enf

orce

r

Tra

nsiti

onal

Gat

eway

Tra

nsiti

onal

Bro

ker

Metro

Met

ro

Web

Ser

vice

TA

Mes

sage

Driv

en B

ean

Ent

erpr

ise

Java

Bea

ns(S

tate

less

Ses

sion

Bea

n)

Bus

ines

s S

ervi

ces

(Coa

rse

Gra

in +

Fin

e G

rain

)

Ser

vice

Age

ncy

Acc

ess

Rou

ter

Tra

nsfo

rmat

ion

Ada

pter

Ser

vice

Age

ncy

Websphere Business

Integrator

Plain Old Java Objects

WBI Components

WAS Components

External Resource

Reusable Services Framework

Remote Queue

Local Queue

Legend

Por

tlet

NIEM XML

IJP – Component Architecture

IJP – Service Orchestration◦ Coarse grain services – support entire business transaction

• e.g., Stolen Vehicle Entry

◦ Service orchestrates multiple fine grain services

21

Ch

an

nel

En

ab

ling

Ser

vice

sLO

B S

yste

ms

Ch

an

nel

sB

usi

nes

s S

ervi

ces

Basic Services

State Police

NCIC DMVAgenc

y X

Orc

hes

tra

tio

nLO

B`

Browser IVRApplicati

onBusiness Partner

Cha

nnel

E

nabl

ing

Ser

vice

sLO

B S

yste

ms

Cha

nnel

s

State Police

NCIC DNVAgenc

y X

Bus

ines

s S

ervi

ces

Orc

hest

rat

ion

LOB

`

Browser IVRApplicati

onBusiness Partner

Intermediary Services

Cha

nnel

E

nabl

ing

Ser

vice

sLO

B S

yste

ms

Cha

nnel

s

State Police

NCIC DMVAgenc

y X

Bus

ines

s S

ervi

ces

Orc

hest

rat

ion

LOB

`

Browser IVRApplicati

onBusiness Partner

Orchestrated Services

Each interaction from CG to FG is an

XSL transformation

IJP Lessons Learned

• Establish end vision, create a roadmap that will get you there

• Roadmap periodically adjusted for changing requirements, delays, emerging technologies, etc

• Identify key stakeholders, their dependencies, and inter-dependencies early on

• Establish, implement, and enforce a robust Governance structure

• Establish a robust transition strategy – minimal disruption of service

• Recognize the importance of training and change management: the new system would only be successful if the people using it embrace the new technology

23

“We’ll be on our way to computerizing all of America’s medical records, which won’t just eliminate inefficiencies, save billions of dollars and create tens of thousands of jobs – but will save lives by reducing deadly medical errors.”

– President Barack Obama, February 4, 2009

Federal CIO council report released recently showcasing NIEM and its rapid adoption within Federal, State, Local, Tribal and International mission partners -http://www.cio.gov/documents/3.12.1-NIEM-Assessment%20Report_Final_Master.pdf

This report highlights an unprecedented opportunity for substantial gains in increasing standardized connections and shared services for cross-boundary information exchange. It challenges the status quo of silos and presents a path forward to a strategy for significant gains for the overall NIEM community.

• Emerging Health Information Exchanges (HIE) are developing the capacity to share patient clinical information among healthcare providers across care settings. This requires:• Standard, Repeatable and Flexible means for defining message

structure• Secure mechanisms to ensure that the right information is shared with

the right user• Address security and privacy policy related issues• Deal with compliance issues• Collaborate with multiple partners • Federated information sharing, identity and authorization management• Cloud based operations

Healthcare Information Exchange

Sounds familiar. We are also facing similar issues, and looking to collaborate with other domains to jointly address these issue….

25

Questions?

WWW.ISE.GOV