Next Generation Paperless Case Management for Investigators and
Analysts
White Paper, May 2003
Office of Special Investigations
Investigative
Information Management System (I2MS)
Concept of
Operations
Issue 1.0
Next Generation Paperless Case Management for Investigators and
Analysts
White Paper, May 2003
Office of Special Investigations
Investigative
Information Management System (I2MS)
Concept of
Operations
Issue 1.0
Revision
History
Table of
Contents
1. Identification 4
1.1 Purpose 4
1.2 I2MS 4
1.3 Business
Need 5
2. System
Concepts 6
2.1 System Features
and Capabilities 6
2.1.1 Investigative Activities includes
the capability to: 6
2.1.2 Files include
the capability to: 6
2.1.3 Participants 6
2.1.4 Query Capability 6
3. Business
Processes 6
3.1 Investigative
Activities 6
3.1.1 Briefing Activity 7
3.1.2 Computer Intrusion 7
3.1.3 Document Review 7
3.1.4 Exception File (Version 1) 7
3.1.5 Interview Details Tab Build Element (Version 1) 7
3.1.6 Law Enforcement Records Check 8
3.1.7 Liaison Activity 8
3.1.8 Media Analysis Support Activity 8
3.1.9 Polygraph (Polygraph Exam) Activity 8
3.1.10 Reportable Situation (300/0) Activity 8
3.1.11 Search Activity 9
3.1.12 Source Interview Activity 9
3.1.13 Specialist Consultation 9
3.1.14 Surveillance Activity 9
3.1.15 TALON Activity 9
3.2 Investigative
Files 10
3.3 Management
Files 10
3.4 Investigative
Support Files 10
3.5 Investigative
Services 11
3.6 Participants 11
3.7 Resources 11
3.8 Common
Functions for Activities and Files 11
3.9 Summary 12
4. System
Justification 12
Concept of Operations
As computers become more prevalent in all aspects of every persons life, a shift in how work is actually done is being seen from one industry sector to
another. . First computers technology affected the
financial sector, then the manufacturing sector, and now next generation
computer power is impacting the more complicated investigative and intelligence case management
sector. . Early computer processing was best fitted to the
straightforward accounting processes. As such, a clear impact on financial institution work
processes was seen. Stock exchange
transactions were no longer done on paper.
Deposits and withdrawals at local banks always required input into a
terminal.
Not long
after the financial revolution in workflow cameThe latest change changes in the manufacturing sector was from a paper-to-keypunch
process to a paperless-online
transaction process. . An inventory manager on a
manufacturing floor changed the way the job was done: it changed from paper based stock receipts and issues that were later keypunched into a
mainframe computer to a more
paperless process. The inventory
transaction of today is done without any paper into the quickly changing, more user friendlyuser-friendly personal computer. . This makes for a real-time
system—the actual event is known, by all those with access to the system at the same
time the event occurred. Now, the The power and flexibility of the computer has now matured enough
to be fully applied to the more complex work of the law enforcement
investigator and intelligence analyst is poised to make a similar
jump. . Software and hardware have
existed for the
investigators for some time but in a limited capacity. . The investigator used word processors for
creating the needed documentation for their clients. . The investigator used databases
to look up information about a person, place, or property to assist in the research aspects of
the job. . More advanced investigative and intelligence
agencies currently use databases to capture the work products and metrics on these
products (e.gfor example,. records management systems, document exploitation,
document scanning).
The
next generation of information management tools for investigative and intelligence agents isintelligence agents is called an Activity Based system. . The Investigative Information Management System (I2MS) is one of the first of these
Activity Based systems for investigative processes. . An Activity Based system is meant to capture all tasks done (and yet to be done) by the agent. . It documents agent “Tooth to Tail”
processes without the less efficient paper forms for entry by a keypuncherdata entry person.
With
this broad coveragecoverage, an Activity Based system
serves several information technology purposes for the agent in one package:
§
Documentation generator for
the agent clients
§
Database repository for agent
research on people, places, or property
§
Resource allocation for agent
management responsibilities
§
Database warehouse for
command wide metrics of cases ( autogenerationauto generation to NIBRS/DIBRS)
§
Evidence, equipment, source,
and expense management in the context of the cases
§
Agent collaboration
(notifications, leading, chat)
This
paper will discuss the system concepts and features of the Activity Based
system, the
advantages of these systems, and their architectural considerations.
With this broad coverage an Activity Based system
serves several information technology purposes for the agent in one package:
Documentation generator for the agent clients
Database repository for agent research on people,
places or property
Resource allocation for agent management responsibilities
Database warehouse for command wide metrics of cases
(NIBRS/DIBRS compliant)
Evidence, equipment, source, and expense management
in the context of the cases
Agent collaboration (notifications, leading, chat)
The
Activity Based system which captures
all aspects of investigative worksystem, which captures all
aspects of investigative work, requires a birdsbird’s eye view of what the
organization does in the context of the investigative work.
Investigative Organization Concepts--The investigative organization, be it insurance,
environmental, educational, DoD, or public, gathers the investigative information in similar ways. . The organization is made up
of teams or units of personnel who perform Activities or tasks. . These Activities are done involving
different participants with different roles. . The cases against these participants are
kept in Case Files.
For example, an individual
may be the subject of an interview. . Or an organization may be the subject of many
document reviews. . And the same
organization may be the subject of an Investigative Case File. First generation Investigative MIS programs do not
require data entry
as these activities are done. . An Activity Based system does.
Relationship of Files to
Activities--The
Files in the
Activity Based system are
the accumulation of work steps. The work steps themselves are documented in
Activities. Activities are smaller, self-contained folder-like records
describing a single Investigative event. The Activity objects document the event. Because there are different
types of events, there are different types of Activities, each with a distinct documentation
requirement. Possibilities for Activities include Interviews, Briefings,
Searches, Document Reviews, Records Checks, Computer Intrusions, and Polygraph
Exams. The Activities gather into a File and all of the
information contained in the Activity is then passed to the file. An Activity may be included in
more than one file, and in such cases, the associated Files share the information. This
association mimics the real world of case investigations when two cases very
closely related are being run simultaneously.
Figure 2 illustrates these File
to Activity
relationships.]
Figure 2: Traditional Paper
Process vs. Activity-Based Digital Process.
Electronic Files vs. Paper files-- The core functional operation of an Activity
Based system resembles
the paper files used to contain the various papers generated to document the
investigative actions. The Activity Based system includes the investigative steps as Activities that are associated
to the Files much
as paper-documented actions are placed in the file folder. Figure 2 also illustrates how the Activity
Based system has segregated out Participant information along with File and
Activity information. This segregation
of these information components commonly contained in paper case files
minimizes agent re-entry work and maximizes information re-use. Participant information is further
segregated out by types of participants: Person, Company, Organization, and
Program. The advantage of this again is
to minimize re-entry of data. The agent
can capture the fact that an individual is a member of a given organization and
then re-use the entered organization information later for other individuals
that may be members of the same organization.
No retyping organization information multiple times.
Figure 3—Sample Electronic Case File from I2MS
Although no organization can be completely paperless,
the Activity Based system can approach this ideal. This is done not only through the segregation and grouping of
data as discussed above, but also by providing electronic tools for those
non-paper tasks done by field agents.
For helping to determine who is responsible for given cases and what
part different agents and agencies might play in a case file, the Activity
Based system provides electronic Assignment functionality. For capturing supervisory review of case
work, an electronic approval and review note functionality is provided. For supplementary case information (e.g.
photos, hard copy documents, audio) an Attachment functionality is
available. And for resource allocation
to case work (e.g. man hours spent, expenses consumed, equipment used) a
Resources functionality is integrated into this paperless system.
The primary advantages of the Activity Based I2MS over many existing investigative software systems are:
1)
Minimization of
duplicate data entry (enter once and reuse by all agents for people, places, property, case
information, evidence, equipment, expenses,……)
Primarily due to the
segregation of data discussed above, agents do not have to enter the same group
of data into the Activity Based system more than once. In fact, agent #2 could reused the person
information entered by agent #1 and not have to do any data entry
2)
Automatic buildup of link analysis data for the investigative analyst
Again, since data is
segregated and re-used, the database behind the Activity Based system is
automatically structured and available for consumption by many graphing
programs:
Figure 4 Example graphical link analysis against system data
3)
Consolidation of “database silos” (I2MS one contingent Oracle database)
Since earlier generation
management systems must contain the scope of new functionality to meet time and
budget constraints, they typically address limited business processes. There exists separate applications and
corresponding databases for these separate business processes. There might be
an application for lists of case files, one for expenses, another for people,
and so on. The next generation Activity
based system has built on past applications and integrated into one interface
for the agent, and one database for management.
This integration of data, in
turn, provides for integration of business processes which, in turn, provides
for database integrity. For example,
equipment used for a case cannot be checked out without the existence of the
case. Or evidence obtained in a Search
Activity cannot be processed without existence of the Activity.
4)
Agent documentation
made as work progresses rather than all at once at deadline
It is not unusual in human
nature to put things off until the last minute. This can happen too in documentation of investigations. Multiple interviews, document reviews, and
searches may have been done before the time a complete report of investigation
is due. The Activity Based system
provides for the entry needed for the immediate documentation needs to suffice
for the later documentation needs. The
agent does not need to what until the last minute to document the case report
because the system can generate this report automatically at any time in the
case life cycle.
5)
Scalable to many
users (based on Oracle backend)
An Activity Based system
requires more entry than the traditional investigative management system. These systems also require access by all in
the organization simultaneously during all parts of the day. A powerful central database is required to
serve these demanding needs. Some
single user databases (like Microsoft Access) or less powerful, less mature
database technologies cannot fit the bill.
The powerful Oracle database behind the I2MS system can. This database is scalable to many users as
already proven on many existing ERP or large web applications.
6)
Rich user interface
for ease of use and
quick entry times (no slow screen refresh)
As mentioned above, the
higher entry needs for the Activity Based system need a powerful database for
the higher transactions. The end user
application also needs a rich user interface to allow the agent to enter the
information efficiently and effectively.
The I2MS interface is user friendly to minimize the learning curve. The fat client architecture also provides
the user immediate feedback of which data fields need input and which are
formatted correctly.
7)
Standalone
functionality for ongoing work when network unavailable
Investigative agents must go
wherever is needed to do the job. This
is often not behind a desk where networks are reliable and fast. There may be slow modem connections
available at the job site or nothing at all available. Because of this, I2MS is made to operate
without any network connection available at all. Much like Microsoft Outlook where emails and tasks can be read,
searched, and composed offline and then synched once connected to the central
repository, I2MS Activities can be worked off line. The agent continues to work even when the network is down.
8)
Strong normalized
database behind the user friendly interface (data integrity, growth,
and scalability)
A normalized database is one
where common groups of information are segregated from one another. Earlier it was shown how Activities, Files,
and Participant information is segmented out.
This segmentation is carried to much lower levels in the I2MS database
structure. A normalized database
provides for cost effective database integrity, database growth.
Many IT decision makers do
not understand, or care to understand, the importance of a normalized
database. It is a technical issue that
they should not get involved in.
However, many legacy databases are finding limits earlier than expected
because the technical architects did not understand the normalized database
either.
9)
Built in XML
Export/Import functionality for data sharing
The purpose of this document
is to describe the intended use of the Investigative Information Management
System (I2MS), for the Air Force Office of Special Investigation (AFOSI). It will describe the AFOSI
business processes supported by the I2MS and the basic concepts of the system,
and will provide the user community with an understanding of the business
problems and opportunities addressed by the I2MS.
I2MS is the
OSI primary application to document investigations. I2MS replaces CACTIS and is
compliant with the Defense Incident-Based Reporting System. CACTIS saw life as
a Management Information System (MIS) that contained metadata or summary data
about the investigations. The investigations themselves remained documented in
a largely a paper process. I2MS is structured to operate the way the agents
operate and to enable digital documentation of the entire investigation.
Management information becomes a byproduct of the documented investigation.
Doing this, however, creates an entirely different orientation for the
structure of the requirements and their relationships.
The
last four advantages briefly discussed in the previous section:
·
Rich user interface for ease of use and quick entry times (no slow
screen refresh)
·
Standalone functionality for ongoing work when
network unavailable
·
Strong normalized database behind the user friendly interface (data
integrity, growth, and scalability)
·
Built in XML
Export/Import functionality for data sharing
all
have an impact on the architectural considerations of a system imposed with
these requirements.
The core
functionality consists of files and activities. The files are in four
categories:
Investigation
Case Files are a class of files directly linked to the agent documentation of
an investigation.
Investigative
Support Files are a class of files the document the efforts in support of an
investigation.
Investigative
Service Files are a class of files documenting services performed by OSI to
support external investigations or other one-time services.
Investigation
Management Files are a class of files documenting the management of
investigations and investigative personnel.A NIBRS reportable Activity
Based system requires much more user input and higher than normal amounts of
data than the first generation case tools. A rich user interface is
required to quickly and efficiently convey to the user that the complete and accurate
information is entered. . This is done in the form of
dynamically changing
pull down boxes based on related inputs, immediate SAVE buttons available when sufficient
data has been entered, or powerful interface controls (date pickers, checkboxes, checkboxes, screenand screen splitters) to aid the
user.
The chart below explains the available architectural choices for a needy rich User Interface:
For a stronger
user interface the choices is between traditional client server and Java
applets. . The next consideration is
available bandwidth. . For those network
infrastructures with
limited bandwidth, the client server approach is more desirable to minimize
wait times for the user entering large amounts of data. . Java applets often times
require downloads along with the data taking up more bandwidth and more time. . Client server applications
already have the interface code available on the local machine. . UnfortunatelyUnfortunately, the client is fatter
requiring a higher maintenance cost in distributed updated components. . ButHowever, this tradeoff must be made
for usability of
the complex, high
transaction Activity Based system in bandwidth
constrainedbandwidth-constrained networks.
The client server approach also leaves the door
open for uninterrupted
agent operation (local mode processing when
network down or unavailable in remote locations).
Summary The files are the accumulation of work steps. The
work steps themselves are documented in Activities. Activities are smaller,
self-contained folder-like records describing a single Investigative event. The
activity record documents the event and calls for the minimal data needed to
fully document the event. Because there are different types of events, there
are different types of activities, each with a distinct documentation
requirement. The activities gather into a file and all of the information
contained in the activity is then passed to the file. An activity may be
included in more than one file, and in such cases, the associated files share
the information. Figure 2-1 illustrates the relationships.
Figure 2-1:
Activities are the core steps that link to the files.
I2MS
is the primary investigative support application in two investigative agencies today. OSI.
Other applications, such as e-mail and Office Automation tools,
provide general support but are also key parts of the total investigative
support system suite. I2MS documents the investigations. The other products
assist in conducting, managing, and documenting the investigations. MDITS and
other information systems support the investigative mission in the classified
environment. Taken as a whole, these are the core OSI systems.
As an Air Force and DoD organization, OSI has systems specific to these larger
components, but the core systems are unique to investigations and the OSI
mission, and must be highlighted for that reason..
However, the activity based system augments other
administrative systems already well established (for examplee.g., Computer Aided Dispatch). . With the XML capabilities of
the Activity Based system, integration with existing databases is
straightforward.
The FORMMS
was developed in response to the DoD initiative in which the DoD established a
simplified baseline of the best, common information systems across the business
functions of the Department. These migration systems represented a stage of
process improvement designed at achieving a common set of automated processes
and practices in the DoD, and help reduce redundant development and support
costs.
The DoD
FMP, with multiple inventory systems maintained by the services, employed a
variety of platforms and applications. There was no common standard operating
procedure nor was there an automated method to query the inventory databases
without manually submitting a query to the individual maintaining the database
and that individual performing a manual search. None of the DoDIIS agencies
systems were "on-line," or interactive. In addition, there was no
automation process to perform the Foreign Materiel Acquisition Requirement
(FMAR), or Foreign Materiel Acquisition Opportunity (FMAO) processes.
There was an unprecedented degree of integration
and interoperability required of the DoD system that supported this program.
The effort required a cohesive, integrated solution that included not only the
inventory requirements but also the acquisition management requirements of the
DoD FMP. There was a need to be able to scale the size and complexity of each
inventory maintained by the individual agencies since the requirements and
number of items maintained and accounted for vary from a few hundred to sixty
thousand plus. There was also a need to track item location and to identify who
is responsible for that item. A standard was required for DoD Foreign Materiel
inventory at the SECRET collateral level for accountability purposes that can
be readily accessed, easily used, and addressable to the needs of the
individuals who maintain the inventory, those foreign materiel managers who
require inventory status, and analysts who require information concerning a
particular item.
The I2MS is a Oracle
multi-user application that will provide functionality to support Special
Investigation and Intelligence
requirements of the AFOSI and be DIBRS compliant. It is a Defense Information
Infrastructure (DII) Common Operating Environment (COE) Level 5 compliant
application that functions with a DOD approved secure Internet Browser
interface.
System
Features and Capabilities
Investigative Activities includes the capability
to:
Create and
track Briefings
Create and
track Computer Intrusions
Create and
track Document Reviews
Create and
track Exceptions
Create and
track Interviews– Subjects, Witness, Victims, and Incidental/Group
Create and
track Law Enforcement Record Checks
Create and
track Liaisons
Create and
track Media Analysis
Create and
track Polygraph Exams
Create and
track Reportable Situations
Create and
track Searches
Create and
track Source Interviews
Create and
track Specialist Consultations
Create and
track Surveillances
Create and
track Talons
Files include the capability to:
Create and track Investigations – Case and
Operations
Create and track Management Files
Create and track Service Files
Create and track Support Files
Create and track Resource Files
Create and track Participants
The query tool allows the
user to query the database for information about activities and files.
This section describes the general business
processes supported by the I2MS.
Investigative Activities are the basic
investigative steps. The individual steps are gathered into a file. The
investigative steps can also apply to more that one file, such as an
investigative event that involves two or more persons. A primary investigative
step must be sufficiently complete in itself because the entire investigation
may be no more than that one-step and the investigation then dropped. There
must be a sufficient number of types of steps to cover all of the work
typically performed by the agents. There are also varieties of types of crimes
and investigations that must be encompassed by the basic investigation steps.
OSI personnel conduct various types of briefings
that are part of the mission. For example, briefings could cover the crime
information at a base, the threats to a facility, or that reside in a location
being entered by Air Force personnel, or other information related to
investigations or discovered in doing investigations. The activity captures
such unique briefing-related information as the reason for the briefing, the
attendees or audience and time and place. The briefing itself can be attached
to the activity for reuse and viewing.
The purpose of the intrusion activity is to alert
the key people involved with the systems under attack to limit any potential
damage. Intrusion attacks are normally treated as a nuisance rather than a
crime or an event requiring lengthy investigation. The current form documents
the information relevant to damage control. A few other data elements would
assist in tracking trends and possibly intrusion sources for later
investigation or use in link analysis. Whenever OSI receives notice of a
possible computer system penetration, the first order of business is to limit
any possible damage. The intrusion may also launch a more extensive
investigation. The first step is to document the intrusion event and the steps
taken to limit the damage. I2MS proposes to maintain the data in the I2MS
database to produce intrusion-related metrics, such as sites attacks, types of
computer system attacked, sources or the attacks and so on.
A document review is a means to gather information
related to an investigation. Document reviews take place to gather information
from official written records held outside OSI. They are for general classes of
documentation: Financial, Contract,
Medical, and Personnel. Some reviews, such as a contract records, can take a
relatively long period over several days or be revisited at several intervals
to check out information learned by other means. Some of the data collected
will populate information on other activities. For example, the personnel
record may yield data for the Subject tab. The location and specifics of the
records are recorded so that the investigation can be repeated if necessary and
the sources of all information traced. The title will indicate sub-type and a
user entered description.
Agents may need a general-purpose file that can act
as a “container” for activities that are not otherwise linked for
investigations or pre-defined purposes. For example, the computer crime
managers may want to collect all intrusion activities into a monthly “folder.”
The activities could all be associated to an Exception file titled as the
January 2000 Intrusion File. A series of briefings could be processed in a
similar way. In addition to such general-purpose uses, I2MS does not maintain
that all possible file types have already been identified. One way to identify
others will be to allow the users to propose new ones. Another way will be to
review all of the exceptions and see if a trend emerges that could be better
serviced with a dedicated file type.
Interview Details Tab Build Element (Version 1)
Interviews are expected to be the most frequently
used type of activity. The activity contains several sub-types:
Witness
Subject
Victim
Incidental/Group
The activity title will include the type and name
of the interviewee.
The purpose of the Law Enforcement Records Check
Activity is to document those efforts in checking a local Law Enforcement
agency records or information. This may be done in the support of an
investigation that a Law Enforcement agency was involved in or in a Personnel
Security Investigation. The activity documents who the agency is and those key
individuals at that agency. The activity itself only captures a given Law
Enforcement Agency and not multiple checks.
Most Counter-Intelligence (CI) related
investigative activities will fall into the predefined types. I2MS will allow
room for two specialized CI Activities; one is a specialized CI Activity and
one is a specialized CI Support Activity. The specialized CI activities may be
to develop a threat analysis by gathering information related to a specific
threat. A group of these activities may be associated to a CI File that results
in an Intelligence Information Reports (IIR) or other report pointing out the
threat and how the threat can be mitigated. With the exception that the focus
of the activity is a CI topic, the file and associated CI Activities, the
process resembles a typical investigation. However, CI “investigations” have
their own context and content and may require a specialized CI Activity and a
CI Support Activity to convey the information.
Media
Analysis Support Activity
OSI supports investigation by performing Media
Analysis of computer media. The analysis can take several directions to recover
or assess the information contained on the media. I2MS records the work
performed. As with other files types, the Support File can be associated with
the Incident File that requested the analysis. The CCI Media Analysis Activity
follows the norm by using common tabs with specialized Summary and Details
Tabs. The Narrative Tab can be used to document the analysis and Attachment Tab
can include any records generated by the analysis if it is not captured as
evidence.
Polygraph (Polygraph
Exam) Activity
OSI is called upon to perform polygraphs as a
service to an agency doing security background investigations. OSI performs CI
and full Life-style polygraphs as needed. These types of security polygraphs
have a defined set of questions. OSI administers the polygraph and reports on
the results. OSI polygraph specialists maintain the detailed results as part of
the record and return the tests to Headquarters for review and validation.
Response sheets are also collected as part of the test and review processes.
Reportable
Situation (300/0) Activity
CI Activities; one is a specialized CI Activity and
one is a specialized CI Support Activity. The specialized CI Activities may be
to develop a threat analysis by gathering information related to a specific
threat. A group of these activities may be associated to a CI File that results
in an IIR or other report pointing out the treat and how the threat can be
mitigated. With the exception that the focus of the activity is a CI topic, the
file and associated CI Activities, the process resembles a typical
investigation. However, CI “investigations” have their own context and content
and may require a specialized CI Activity and a Reportable Situation Support
Activity to convey the information.
There are several types of searches: crime scene,
person, vehicle, or facility. If on a military base, the search requires a
command representative to authorize the search. Otherwise, other authority is
required. The authorizing form letters are built into the common Attachment tab
along with the remaining forms needed for investigations. The unique activity
information is such things as the time, place, and the circumstances of the
search to include authorizing authority when required. The results can be
documented in Narrative and Notes. Evidence can be captured in the Evidence,
and so on.
Source Management is a separate I2MS module. The
Source Interview Activity is used because the interview will be associated with
an Investigation File and to a Source Management File. One documents the
information for a specific investigation and the other for a specific source.
The source will be indicated with an identifier code, such as the recruiting
detachment number and a sequential number for that detachment’s sources. Only
the Source Management File will contain the actual biographic information and
be access controlled. Because the identity is masked, the Source Interview can
have general access as part of access to the investigative record.
Specialists are called upon to determine if their
participation in the investigation would add value. The specialist are
consulted to assist and recommend if and what further specialist support would
assist the investigation. They answer the question “should more be done.” The
consultation is a review of the status of the information contained in the
investigative record to date discussion with the lead and support agents, as
appropriate, and perhaps discussion with other specialists. The activity will
then be associated with the investigation and so that the lead agent can take
any further action. The results of the specialist review will be entered in the
Narrative. There are four selectable sub-types of specialist investigations:
Forensics
Technical
Equipment
Polygraph
Computer
Crime
Investigative operations range from the very basic
unsophisticated drug purchase to longer-term surveillance or undercover
operations. Thus, not all operations require detailed planning. When required,
plans should meet a minimum standard of coverage. An approved standardized
template that also acts as a planning checklist has been developed so that I2MS
can improve the process. OES often only sees the plan after the operation is
over and when it is too late to make helpful recommendations or reduce risks.
Recent terrorist threats to the U.S. have triggered
immediate responses from all military forces to effectively and collectively
process possible counter intelligence information. Although mechanisms were in
place to gather and disseminate longer-lived intelligence information through
the IIR, a different mechanism for swiftly processing time critical Force
Protection Information was implemented using a Microsoft Access application
developed and implemented under the Defense Counter Terrorist Working
Committee. With an Access implementation, it allowed for quick implementation
with a common format for electronically sharing the data between the various
DoD services. With this TALON implementation, a set of business process rules
for AFOSI (and other Agencies) has now been established. In particular, these
process rules define the type of information, the reporting format, and the
reporting hierarchy to be followed.
The core part of I2MS is those functions most
directly related to documenting the investigations. The activities discussed
above are the investigative steps performed in the investigative process. The
individual steps need to be gathered and linked to make up the complete record
of the investigation. The Investigative Files are the mechanism for gathering
and using the activities to construct the complete record. The Investigative
Files contain common information and then other information specific to the
level of investigation. The Investigation Files include:
Case
Operation
In the case of Investigative Files, the Case File
is the most complete file. The Operations File contains a trimmed down versions
of the Case File.
Investigation Management covers all of the
functionality related to the management of the investigations and the OSI
components that indirectly support the investigative processes.
There are a variety of management functionality
used in supporting the organization and investigations. The dimension of the
management functionality includes:
Applicants
Collection
Requirements and Collection Emphasis
Equipment
Evidence
Management
Geo
Personnel
Source
Management
Target
Management
Technology
Units
The files contain a variety of different
functionality; yet, the functionality is contained in the same general format
and structure as the other functionality.
The core investigative process is supported by work
needed to augment the investigation. The work is often called on “by
exception,” that is, only when needed by the nature of the investigation. The
functionality for support also tends to require specialists trained to perform
the work. The functionality is also distinct from the Investigation Files.
These factors lead to the use of Support Files tailored for the supporting
functionality. The Investigative Support Files include the following:
Criminal
Polygraph
Seven
Contacts
Source
Development
Technical
Surveillance
Undercover
Operations
Undercover
Operations Support
OSI occasionally performs services, one-time events
as opposed to a continuing investigation. The work is often called on “by
exception,” that is, only when needed. The services’ functionality also tends
to require specialists trained to perform the work. The functionality is also
distinct from the Investigation Files. These factors lead to the use of Service
Files tailored for the functionality. The types of Investigative Services
includes:
Counter-Espionage
Operations
Counter-Intelligence
Investigations
Counter-Intelligence
Services
Force
Protection Services
Personal
Security Investigation
Threatened
Airman Support
There are four types of participants: Person,
Company, Organization, and Program and there are four types for each
participant: Subject/Victim/Witness/Incidental and Group used in DIBRS and
I2MS. I2MS uses the standard file structure to gather information in I2MS
involving a specific person, company, organization, or program. For example,
all files and activities dealing with a program regardless of role will be
associated together in a single program file. Such cross-references make it
easier to revisit information for one of the entities that has had several
roles in the I2MS context. These files also make it easier to cross-reference
persons who belong to a company or program to look for common denominators.
I2MS has four operations that are initiated with
agents but that are then managed across the entire command. The management
behind each of these areas is different and will not fit the common model for
I2MS. Separate modules are used to contain the functionality not directly used
in the files and activities to manage. The resources include:
Cfunds
Equipment
Travel
WorkHours
Common Functions for Activities and Files
One overall objective was that all I2MS components
have a similar “look and feel” and general operation. This reduces the need for
detailed training because the functionality will be intuitive from one area to
another due to commonality in layout and operation. Activities and files have a
set of common functions.
Assignment
Association
Attachment
Narrative
Notes
Reports
Resources
The purpose of the Summary Tab was to rapidly show
the top-level information and status of the investigation. The summary
information includes, but not limited to:
General
Summary
Closure
Information
I2MS is an integrated solution that supports the
entire U S Air Force Office of Special Investigation with a complete system for
managing their Investigations and Intelligence business process using state of
the art technologies and software development techniques.