Product
Specs: Family Violence Coaltion Application (FVC-APP)
CDI-11 – FVC-APP Product Analysis (MI Phase 3)
FINAL VERSION
April
7, 2000
Table
of Contents: 1.Introduction
1.1.Overview
of Data Collection Considerations (READ THE OVERVIEW)
1.2.Introduction
to the Integrated Garrett Data Mart
2.Product
Resolution
2.1FVC-APP
Requirements
2.1.AMain
Menu 2.1.A.1Enter
New Incident Screens
2.1.A.2Administrative
Access Screens
2.1.A.3Analyst
Access Screens
2.1.A.4Exit
Screen
2.1.BFile/Exit
Menu
2.1.CPublic
Reports Menu
2.1.DHelp
Menu
2.1.ECIHM
Security
2.2FVC-APP
Solutions
2.2.AMain
Menu
2.2.A.1Enter
New Incident Screens
2.2.A.1.aIncident
Data (Tab 1)
2.2.A.1.bVictim
Data (Tab 2)
2.2.A.1.cInvolved
Persons (Tab 3)
2.2.A.1.dCriminal
Proceedings (Tab 4)
2.2.A.1.eCivil
Actions (Tab 5)
2.2.A.1.fServices
(Tab 6)
2.2.A.2Administrative
Access Screens
2.2.A.2.aLookup
Table Administration Screens
2.2.A.2.bUser
Administration Screens
2.2.A.2.b.1User
Role Permissions
2.2.A.3Analyst
Access Screens
2.2.A.4Exit
Screen
2.2.BFile/Exit
Menu
2.2.CPublic
Reports Menu
2.2.DHelp
Menu
2.2.ECIHM
Security
2.2.FDatabase
Security
3Conclusion
AUTHOR:Corey
Ellsworth
FIRST
DRAFTAugust 31, 1999
REVISION
19/24/1999 by Corey Ellsworth
REVISION
2:1/18/2000 by Lucia Biers
REVISION
3:1/20/2000 & 1/28/2000 by Corey
Ellsworth
REVISION
4:3/15/2000 (L. Biers) 3/31/2000 (C.
Ellsworth)
FINAL:4/7/2000
by Lucia Biers with minor updates of
5/17/200
by Corey Ellsworth
2.1.FDatabase
Security
1Overview
and Introduction
1.1Overview
of Data Collection Considerations
The
overall goal of this project is to set up an interagency incident-based
system to document the prevalence of family violence in Garrett County,
Maryland without compromising individual privacy. As documented in the
literature on this subject, many incidents of family violence are never
reported to law enforcement. The Garrett County Family Violence Coalition
(FVC) data collection system will aggregate existing data from law enforcement
with self-reported victim data collected by other local service providers.
The following material on incident-based reporting served as a guideline
for the design of the FVC Application (FVC-APP).
The
National Incident-Based Reporting System (NIBRS) defines an INCIDENT as
"one or more offenses committed by the same offender or group of offenders
acting in concert at the same time and place." An incident is thus a single
event during which multiple offenses or crimes may be committed and with
which several victims and offenders may be associated.
The
aggregate statistics for NIBRS offenses, victims, and offenders may be
greater than the number of reported incidents. A single offender may have
multiple victims or may commit multiple offenses against a single victim,
or multiple offenders may attack a single victim. The # of offenses, the
# of victims and the # of offenders vary from incident to incident, since
each is an independent phenomena.
Traditionally,
criminal and non-criminal incident reports (including incidents of family
violence) are officially recorded and tracked by one more of the following
entities:
·Law
Enforcement
·Prosecution
·Courts
·Parole
& Probation
·Corrections
·Social
Services (for cases involving child maltreatment)
There
is general agreement that many incidents of family violence are never reported
to the above authorities. (Estimates of under-reporting vary, with perhaps
only 10-25% of family violence incidents ever being reported.) Furthermore,
a recent evaluation of law enforcement practices in New York State indicated
that over 20% of domestic violence incidents classified as "non criminal"
involved criminal conduct. Physical aggression, threats to injure, harassment
and property destruction by the suspect are examples of behaviors classified
as non-criminal by investigating officers.
For
the FBI's NIBRS, both incidents and arrests are reported
for certain serious "Group A Offenses," while for less serious "Group B
Offenses" only arrests are reported.
In
order to simplify data collection for the pilot FVC database, an incident
shall be viewed as having only one victim. Two separate victims who are
involved in the same NIBRS-defined incident shall be identified in the
FVC database as two separate “FVC incidents.” However, the data entry screen
allows for entry of multiple victims, so it will also be possible to link
multiple victims with a FVC “record number.” This dual approach to tracking
is necessitated by the fact that – with the exception of law enforcement
and the courts– many service providers may not have knowledge of multiple
victims who are linked to a single incident. Support services are often
targeted to an individual victim. The FVC-APP also deliberately avoids
identifying the exact time of the incident and the street address where
the incident occurred in order to preserve individual privacy. These privacy
considerations limit local implementation of the NIBRS incident-based system,
but serve the project’s purpose of providing aggregate anonymous statistics
on the incidence of family violence.
For
the purpose of tracking the prevalence of family violence in Garrett County,
MD any and all incidents of family violence reported to staff at any of
the participating organizations will be entered electronically into the
Family Violence Coalition database. Identifying information for an individual
(name, date of birth and gender) will be electronically "hashed." Aggregate
tracking of incident-based data will be facilitated through a non-identifying
record-linking strategy that employs "hash alias resolution tables." Each
"FVC incident" of family violence may not only involve multiple offenses
and multiple offenders, but a variety of (often duplicative) services may
be provided by a multiplicity of organizations who are working with the
same victims, offenders and/or witnesses (including children) who are involved
in an incident.
The
anticipated outcome of the FVC-APP implementation is to demonstrate the
efficacy of a multi-systems reporting and tracking database. Reports based
on aggregate data being will be used for planning and systems resource
allocation purposes. The vision of the Garrett County Family Violence Coalition
(GC FVC) is that participating organizations will work together on a system-wide
approach to prevention, detection, prosecution and treatment of family
violence. The FVC-APP is focused on providing a method of tracking progress/lack
of progress toward this vision.
Selection
of data elements for the Garrett County Family Violence Coalition's Incident-Based
Electronic Data Collection Reporting System - the "FVC-APP" - has been
an on-going iterative process. The accompanying document, FVC-APP Details,
contains recommendations for data fields and data elements (including Lookup
Tables/look-up tables) for the FVC application. In effect, when signing
off on the CDI-11 FVC-APP specifications document, contributors to this
project are agreeing that this data is a priority slice of the overwhelming
set of possible data elements that are employed in the tracking of family
violence.
·Data
sets for the demographic data fields are based on the 1990 and 2000 census
codes.
·Data
sets for the victimization subcategories are from the VAWA Subgrant Award
Report, and MD COMAR.
·Data
sets for the offense categories are partially based on the NIBRS Data Elements/Values.
·Data
set for the Service Domains is aligned with the Federal Community Service
Block Grant funding categories.
The
definition of "family violence" adopted by the GC FVC encompasses partner
abuse, elder abuse, child maltreatment and sexual assault. The formal definition
of "Domestic Violence" adopted by the federal government has sometimes
been interpreted to exclude offenses committed by non-related persons known
to the victim. For FVC-APP data collection purposes the term "family violence"
has been broadly interpreted to include related offenses committed by persons
who are either known or unknown to the victim (e.g. stalking, child sexual
assault, etc.).
There are still many unresolved issues in attempting to design an incident-based system to track the prevalence of family violence. Domestic abuse is often a continuum of violent actions and does not consist of a single incident. Data collection is complicated by the fact that actions that are not normally considered violent may become violent offenses when viewed as part of an over-all behavioral pattern by the offender (e.g. intimidation). Domestic abuse may be a continual state of victimization, which involves repeated victimization of the same person by one or more offenders. When the victim can not identify the details of discrete victimizations and more than five victimizations occurred in the previous 6 months, then the National Crime Victimization Survey assigns a "series crime incident" designation to this occurrence. For tracking purposes the FVC-APP will record the duration of the abuse when a victim reports multiple incidents.
Domestic
abuse may involve a wide variety of criminal actions that range from minor
to serious offenses. For this reason, the required offense-specific information
may vary widely. The initial FVC-APP does not attempt to be all-inclusive.
The goal is to minimize data collection, while at the same time obtaining
information that can be useful for system analysis and planning. It is
anticipated that the FVC-APP prototype will evolve as future enhancements
are added.
1.2Introduction
to the Integrated Garrett Data Mart
The FVC-APP that is detailed in this document is one of many parts that comprise the Garrett County Data Mart.The FVC-APP will access an online transaction processing (OLTP) SQL Server 7.0 database called FVC-DB.The FVC-APP will provide screens for data entry, query capability, help, reporting, and database administration. Client confidentiality and the privacy of any potentially identifying information will be ensured through implementation of the CHIM Standard Hashing Algorithm (SHA-1) software under development as CDI 10 of this integrated project. Security will also be implemented in the FVC-APP in conjunction with the security features of the SQL Server 7.0 and the Windows NT operating system.The FVC-Database will interface with a separate online analytic processing (OLAP) SQL Server database called MART-DB under development as CDI 16 of this integrated project.
This application will be developed using Microsoft Visual Basic 6.0.The interface will consist of Multiple Document Interface (MDI) forms.The MDI scheme will allow the FVC-APP to have multiple 'child' forms displayed on one 'parent' form.This makes for an user-friendly interface.The remainder of this document will detail the FVC-APP interface. A desired future enhancement for the FVC-APP is to enable data entry online through a web-based interface.
2Product Resolution
2.1FVC-APP
Requirements
The following sections will detail the requirements of the FVC-APP as defined in the document “Performance Requirements Specification – Section 5.” This document also incorporates all updates to product specifications as agreed on by involved parties through a series of face-to-face meetings and exchanges of information during the period 10/1999 through 4/2000. Menu screens will present program options to the user.There will be both main menus and sub menus.All menus will be presented in the same format and style to provide a standard look and feel throughout the application.
2.1.AMain Menu
Upon execution of the FVC-APP the Main Menu will be enabled. There shall be four sub-menus on the main menu. The functions of each of the five sub-menus are described in detail in the FVC-APP Solutions section of this document. The four sub-menus and their main functions are:
2.2.A.1Enter New Incident Screens - authorized users enter an incident-based record
2.2.A.2Administrative Access Screens - administrate and maintain the database, includes Lookup Table administration and assignment of user IDs and user role permissions. This role generally excludes functions assigned to the analyst role.
2.2.A.3Analyst Access Screens – The analyst queries and analyzes data in the FVC-DB and creates new reports with Crystal Report Writer. This role excludes functions assigned to the database administrator role. (A future product enhancement will allow authorized “agency” analysts to query data records "owned" by their agency or program.)
2.2.A.4Exit Screen - exit application
2.1.BFile/Exit Menu
As with any application, there must be a way to stop program execution and return control to the operating system.The File/Exit menu will accomplish this.
2.1.CPublic Reports Menu
The FVC-APP must have the ability to run pre-defined public reports.The reports will be available to all users who access the FVC-APP.A basic set of 4-6 public reports will be “hard-coded” into the pilot system. (In future enhancements, the ability to generate public reports on the fly may be added.)
2.1.DHelp
Menu
The FVC-APP must have a help facility to allow users to view instructions and guidelines on how the software can be used.The help facility will simply be a file, either text or html, for the pilot system.
2.1.EClient Identification Hashing Module (CIHM) Security
Within the FVC-APP and FVC-DB hash alias resolution tables will be used to track individuals throughout the system. In order to avoid using names in the FVC-DB the Client Identification Hashing Module (CIHM) will hash name, gender and date of birth into a 160 bit binary number using the Federal Standard Hashing Algorithm (SHA-I).A hash alias resolution table will be created for each individual by repeating this procedure for all possible known aliases. This module will be invoked before data is sent to the FVC-DB, so individual names will never be stored in the FVC-DB. Additional details of how the FVC-DB will interface with the MART-DB - without revealing the hash alias - are delineated in section 2.2.E of this document.
2.1.FDatabase Security
The FVC-APP must implement a security scheme that will ensure data security, not only from outside sources, but from internal sources as well.The security of the database is of utmost importance and must be carefully planned to ensure security of the information.
2.2FVC-APP
Solutions
The following sections will describe the proposed solutions to each of the requirements of the FVC-APP.Features and functionality discussed in these sections will be implemented by the completion of MI phase 6.
2.2.AMain
Menu
There will be multiple menu screens throughout the FVC-APP.All menus will consist of a Visual Basic form with buttons.Beside each button will be the menu action that corresponds to that button. The main menu will appear when the application is executed. There will be a series of up to 5 active buttons on the Main Menu screen that will present program options to the user, depending on what roles the user is assigned to.There will be both main menus and sub menus.All menus will be presented in the same format and style to provide a standard look and feel throughout the application. Current screen configuration uses the configured Windows color scheme to display menus, forms and field headers.A 12-point black font is used on a white background for data entry fields.A method of color-coding the minimum required data set is desired.Specific menu screens will be discussed in the following sections of this document.
2.2.A.1 Enter
New Incident Screens
When the Data Entry Technician (DET) chooses “Enter New Incident” from the main menu the incident input form will be loaded.The incident input form will be a multi-tabbed form that will contain input fields for all editable fields in the FVC-DB.The tabs of the incident input form will be accessible in progression.Upon completion of one tab, the next tab will become available.At any time prior to selection of the "Send all data to the FVC Database" button, the DET will be able to toggle back and forth to all tabs to update data entry for an incident record. (The one exception to this "update" capability is the CHIM function - which creates a hashed ID number instantly. Any errors in entry of DOB, GENDER and/or NAME can be remedied by the creation of another hashed alias with the corrected information.).The following sections will detail each tab of the incident input form individually. The FVC-DB will accept each victim record as a separate “FVC incident.” For tracking and analytical purposes all data entered prior to invoking the “Send all data to the FVC-DB” feature shall be treated as a NIBRS incident record.
For additional specifications for each field on the incident input screens as well as the initial set of Lookup Tables refer to the screen shots and the “FVC Details” document, which are appended to this document.
2.2.A.1.aIncident Data (Tab 1)
Refer
to the screen shot of Tab 1 – “INCIDENT DATA" for field layout and form
design.
The first accessible tab on the New Incident Form is the “New Incident” tab. On this tab the DET will enter information about the incident that is being reported.Since a “FVC incident” is victim-based, information from this tab as well as the identity of the victim from the victim input screen shall define a “FVC incident” in the FVC-DB.
2.2.A.1.bVictim Data (Tab 2)
Refer
to the screen shot of Tab 2 – “VICTIM DATA" for field layout and form design.
The second accessible tab on the New Incident Form is the “Victim Data” tab. On this tab the DET (data entry technician) will enter information about the victim and household composition. For each “NIBRS incident record” in the FVC-APP it shall be possible to enter multiple victims by selecting the “”Enter Another Victim Record” button. For each subsequent data entry screen the DET shall select one of the victims entered for the “NIBRS record” prior to entering additional data. There will be record counters on the “victim data” tab.The record counters will tell the DET how many victims have been added. To toggle between different victims there will be navigation buttons at the bottom of the “Victim Data” tab.The DET will use these buttons to navigate through the different victim records that have been entered.
The CIHM shall be invoked as described below when the “Enter Another Victim Record” function is selected.
When
the DET is finished inputting data they shall click on the "Go to Involved
Persons" button located at the bottom of the “Victim Data” tab.When
this button is "clicked" it shall invoke the CIHM that will prompt for
all aliases for the victim and provide a screen for the entry of all names
and aliases to be hashed into the ID_HASH table of the FVC-DB. After the
CIHM has finished, the “Involved Persons” tab shall become available and
receive focus. Refer to the attached screen shot for field layout and form
design for the "Hash Alias" screen. If the victim's hashed alias already
exists in the FVC-DB, then, the hash alias screen will NOT pop up. The
DET entry technician will simply note that another record for this person
exists in the FVC-DB. The DET will not have any additional information
or any access to any previous records for a victim with an existing "hashed
alias match."
2.2.A.1.cInvolved Persons (Tab 3)
Refer to the screen shot of Tab 3 - "INVOLVED PERSONS" for field layout and form design.On the “Involved Person” tab the DET shall enter all required information known for the alleged offender/unknown offender, any witnesses, and/or family members.All information that is on the involved persons screen shall be linked to one of the victims entered on the previous screen. Once again, when all data has been inputted the DET will click the “Next Record” button.This action shall invoke the CIHM for the additional involved persons.The set of aliases for each person shall be linked in a “hash alias resolution table.” See CDI-10 for details of the CIHM interface.
The "Involved Persons" tab will be used to gather information on the alleged abuser, any witnesses and/or members of the victim's household. Basic demographic information gathered shall be identical to that of the “Victim Data” tab – with the exception of household composition and marital status.
Once the DET is finished inputting an involved person record they shall have the option to click the “Enter Another Involved Person Record" button.This will clear the form and allow the DET to enter data for another involved person.Also, there will be record counters on the “involved persons” tab.The record counters will tell the DET how many involved persons have been added.
To toggle between different involved persons there will be navigation buttons at the bottom of the Involved Persons Data” tab.The DET will use these buttons to navigate through the different involved persons that have been entered.
When the DET is finished inputting an involved person they will click on one of three buttons at the bottom of this screen: 1) Enter Another Involved Person Record 2) Go to Criminal Proceedings 3) Go to Civil Actions. It should be noted again that the CIHM is invoked immediately when the identifying information (Name, gender, DOB) is entered.
2.2.A.1.dCriminal Proceedings (Tab 5)
Refer
to the screen shot of Tab 4 - "CRIMINAL PROCEEDINGS" for field layout and
form design.The DET must select
a victim name from the list of victims that have previously been entered
for this NIBRS incident record. The “Criminal Proceedings” data tab will
allow the DET to input data concerning criminal charges brought against
the offender during the current incident.This
form handles the input of multiple charges against single or multiple offenders
by allow the DET to choose from a drop-down list of offenders and then
choose the charge brought against that offender.An
unlimited number of charges can be input for each incident.
2.2.A.1.eCivil Actions (Tab 5)
Refer to the screen shot of Tab 5 – “CIVIL ACTIONS" for field layout and form design. The “Civil Actions” data tab will allow the DET to input data concerning civil actions that are related to the current FVC incident.Once again a victim must be selected for each civil action, and unlimited civil actions can be entered for each FVC incident.
2.2.A.1.fServices (Tab 6)
Refer
to the screen shot of Tab 6 – “SERVICES" for field layout and form design.
The “Services Data” tab will allow the DET to input data about the various services that any victim or any "involved person" receives. This tab will also allow for input of multiple services per individual.When the DET is finished they will click the “Send all data for this incident to the FVC DB" button.This will input the entire NIBRS incident record and all of the separate “victim-defined” FVC incidents into the FVC-DB in one batch operation.
2.2.A.2Administrative Access Screens
The following three sections will detail the administration screens and menus that will allow the database administrator (DBA) to administer the FVC-DB. The menu item “Administrate FVC Database” shall only be enabled when the DBA has logged on. When any other user is logged onto the system this menu option shall be “ghosted out.” The DBA will be restricted to accessing only those system files necessary for database maintenance and the assignments of access privileges for FVC-APP users. To access administrative features the DBA will click on the “Administrate FVC Database” button on the main menu.This will display the administration menu with options to administrate Lookup Tables or users for the DBA role. The role of the DBA is restricted to administration of system set-up (including Lookup Table administration) and operations only. The administrative menus are discussed in greater detail in the two sections that follow.
2.2.A.2.aLookup Table Administration Screens
On
the Lookup Table administration menu the user with DBA access privileges
will be presented with a list of all Lookup Tables.The
user will simply click the button next to the Lookup Table that is to be
edited and a Lookup Table addition form will be loaded.This
form shall contain fields to enter the Lookup Table data items and the
Lookup Table code. When the user is done entering data they will click
the “Add” button.A prompt will ask
for verification of the information.Upon
verification the item will be added to the appropriate list and the Lookup
Table administration menu will be loaded again. Lookup Table administration
is exclusively restricted to the DBA role. However, the database will contain
a "Lookup Table Administration Log" table that will track and document
all Lookup Table updates. The DBA shall not be able to delete or modify
existing items in a Lookup Table.
2.2.A.3.bUser Administration Screens
On the user administration menu the database administrator (DBA) will be presented with the option to INSERT, DELETE, or UPDATE a user’s permissions. If the DBA chooses to add a user, a form will be loaded that contains the following fields:
USER ID – This will be a text field.The DBA will type a valid SQL Server User ID into this field.
USER PASSWORD – This will be an encrypted text field. The DBA will assign a user password for each SQL Server User ID.
USER NAME – This will be a text field.The DBA will type the username of the user to be added.
ROLE – This will be a drop down box containing all roles on the FVC-DB.The DBA will select the role(s) the new user will be a member of. Note that it will not be possible for the DBA to assign any additional roles and/or permissions to the DBA user ID. When complete, the DBA will click the “Add User” button to add the user to the database.
If the DBA chooses the “Delete” option from the user administration menu they will be presented with a dropdown list of all users on the FVC-DB.The DBA will select the user(s) to be deleted and click the “Delete” button.At this time the deleted user IDs and usernames will be removed from the FVC-DB.
If the DBA chooses the “Edit” option from the user administration menu they will be presented with a dropdown list of all users on the FVC-DB.The DBA will select one user and click the “Edit” button.A form, identical to the user entry form, will appear with the user’s information already filled in.The DBA will make the proper edits and then click the “Commit Changes” button to update the user’s permissions.
2.2.A.2.b.1User
Role Permissions
User
role permissions will be assigned by the DBA. However with the exception
of Lookup Table administration and all permissions assigned to the "public"
role - the DBA role will be blocked from access to SELECT, INSERT, UPDATE,
DELETE, or to RUN REPORTS or QUERY database records. See discussion below
for detail.
ÞFVC_DBA
Role[1]
As a product security feature, permissions assigned to the FVC_DBA role can not be amended - unless the database developer updates the source code of the product.Members of the FVC_DBA role will have all public permissions as well as permissions to UPDATE, INSERT, SELECT and DELETE user accounts and INSERT into Lookup Table tables.
ÞPublic Role
Permission to SELECT (view) all reports included in the "global" access category and SELECT from Lookup Table tables. No other privileges are assigned to this role. This role may be assigned to persons who wish to "test" the product, including people from remote locations down-state who will be given a User ID with dial-up access. Under this set up funders will be able to download public aggregated reports as needed!
ÞData
Entry Technician (DET) Role
Permission to INSERT data only. No UPDATE, DELETE, SELECT capabilities for this role - with the exception of all permissions for the public role as stated above. Although, in theory any one User ID may be assigned certain multiple roles (except for the DBA role), a User ID may NOT have "analyst" role access permissions simultaneously with the DET role.
ÞAnalyst
Role
The Analyst shall administrate all query and report features of the FVC-DB. Permission to view (select) all tables in these databases - with the exception of the hash alias resolution table and the allied hashed ID functions. See the Analyst Access / Query Administration Screens section below for additional detail. Under no circumstances shall the Analyst be able to INSERT, UPDATE or DELETE any data. Analyst access will be restricted to SELECT and REPORT features. Initially there will be a “FVC Analyst” role. A more global “MART Analyst” role may be granted identical permissions when the FVC-DB is integrated with the MART-DB. Permission to assign User ID’s certain access privileges to queries and reports that are created by the analyst is a desired feature that may be added to a subsequent version of the FVC application.
2.2.A.3Analyst Access Screens
The Analyst Access menu option will enable persons assigned to the Analyst role to access Crystal Reports to run reports. The Analyst will be able to author custom reports on all data in the FVC database - with the exception of the hash alias resolution table and allied hashed-id functions.
2.2.BFile/Exit
Menu
The "exit application" function is executed by the selection of the Exit option on the File pull-down menu on the upper left-hand corner of the application header. A second method of exiting the application is to select the "Exit" button on the main menu.
2.2.CPublic
Reports Menu
The Public Reports Menu is the pull-down menu that is accessed by the selection of the Public Reports option on the header of the application. Reports listed under the report menu will be global access. All users of the FVC-APP will have access to run these reports.
2.2.DHelp
Menu
The Help Menu will be located on the header of the application directly to the right of the query menu. Initially, the help menu will open a text file prepared by the FVC Coordinator to provide the database user with 1) Instructions for Data Entry and 2) Data Element Definitions for each field in an incident record.
2.2.ECIHM Security
Since no names will be used in the FVC-DB it will be necessary to have a way to securely identify individuals within the database without using their names.To do this a Client Identification Hashing Module (CIHM) will be developed.This CIHM will provide two functions.One function of the CIHM will be to hash an entrant’s name, generation, date of birth and gender into a unique 160-bit number. Generation of a unique one-up “FVC ID number” as a product of the hash alias resolution table is the second function of the CIHM. The FVC-APP will utilize both functions of the CIHM.Details on the CIHM can be found in the document CDI-10. (The CIHM ability to generate and gather aliases will be replicated in the MART database, which is to be implemented as a related component of this project.)
2.2.FDatabase Security
The FVC-APP will use SQL security.This means that each user will have an associated FVC-DB userid assigned to them.When the application is started a logon screen will be presented.The user will enter his/her FVC-DB userid/password and the system will authenticate that ID.After the user has been authenticated, the system will query for the role.Once the FVC-APP has obtained the user’s role from the FVC-DB authorized users will be able to access certain features.Please refer to the sections describing the database roles for additional security information.
3.0Conclusion
Using this document as a guideline, a prototype FVC-APP shall be constructed.All screens and features covered in this document will be included in the prototype by the completion of MI phase 6.The CIHM will be implemented along with an initial set of incident insert and retrieval capabilities.Work on the FVC-APP prototype is well on its way.Refer to CDI-03 for completion time estimates.
