ICBR DATABASES

• In the following slides we will showcase a few of the databases that help to run the ICBR.

• Listed are the data collection GUI (made for every study we conduct), the datawarehouse (stores the data we collect), and project management (tracks information about data and allows us to run reports).

• All of these databases run on Filemaker Server which is securely housed in our Center. Running the databases on Filemaker allows us to securely access the data from any Filemaker client and provides an interface for conducting our research.

• Content in the various databases are an example of a previous study focused on aging through the DHS.

DATABASES

DATA COLLECTION

SUBJECT

• This is the subject portion of the data collection GUI. In this tab we collect basic information about the subject.

• Every visit we will collect the same basic information. If the subject has already been in a study, their information is already stored and does not need to be recollected.

GOVERNMENT ID

• This is the government ID portion of the GUI. In this section we input the information about the ID and scan the government ID.

• The face and signature image are later entered into the database manually.

MOET

• In this section we collect what we call MOET which stands for moisture, oiliness, elasticity, and temperature.

• The MOET information is collected from a handheld device and is entered into the database.

IRIS

• This is the iris section of the GUI. Here we input the subjects attempts while using the iris camera.

• During this data collection, the subject was allowed 25 attempts to successfully collect both irises which was denoted by the radio buttons in each attempt.

CORRECTIVE ACTION REQUEST

• This section is included in every GUI. The corrective action request (CAR) is used to report any issues that need to be fixed during the data collection.

• Requests are automatically emailed to the person they are assigned and once complete, the assigned administrator will mark its status as complete.

PREVENTIVE ACTION REQUEST

• This section is similar to the CAR section except that this is used to note any issues that we see happening before it becomes a problem.

• This section allows us to keep track of any changes that need to be made or have been made during testing, if necessary.

PAYMENT

• Lastly, this is the payment section. In the payment section we mark whether the subject has been paid and mark them as complete.

• Completing their visit ensures all the data is securely stored and stores the information about a payment in our project management database for record keeping.

DATAWAREHOUSE

DATAWAREHOUSE MAIN

• This is the main screen in our datawarehouse. The datawarehouse is the brains behind everything.

• In this tab of the datawarehouse, it stores the information about a specific sample we have collected, whether it’s fingerprint, iris, face, etc.

• Information stored would be data like collection date, subject number, or what modality and subtype the sample is.

• Here we can query information about the sample and use this to create dataruns for future use.

DATAWAREHOUSE MOET

• This section is the MOET section. This is where the MOET information is stored when it is collected through one of our GUIs.

• The MOET information is linked to a specific fingerprint sample.

DATAWAREHOUSE DATARUNS

• The last portion of the datawarehouse is the dataruns section. In this section we create dataruns that we later associate with a project.

• Dataruns contain a selection of samples which range from the entire set of data from a study or a small section such as right index fingers on the first visit from our data collection in 2012.

PROJECT MANAGEMENT

PROJECT MANAGEMENT MAIN

• The last piece of our databases is the project management database. This database houses the tools needed to run each project.

• In this database we can run reports on dataruns, monitor employee hours, track expenses for a project, and manage our inventory.

PROJECTS

• This is the project tab where we store the information about a specific project.

• The project tab stores mainly dataruns, which we list for every project in case we need to go back and revisit a project for follow-up or replication. The dataruns are a depiction of the exact data used in a study.

REPORTS

• Within the project tab we can run various reports. In this example, this is an age report.

• An age report tells us the breakdown of age across a datarun.

• We can also run other demographics such as gender and ethnicity as well as reports on failure to enroll, quality data, and how many visits per day a project has.

TIMESHEETS

• The last main feature of the project management database is the timesheets tab.

• In the timesheets tab we track an employees hours put into each project to allow for proper billing and to ensure all employees are working on the required tasks.

• This also allows us to monitor the amount of time test administrators have been data collecting and allows us to put resources where they are necessary.