A Little Surprise from DCJS - Domestic Violence reporting on UCR
05/17/2008 08:52 Filed in: PolicePro
On Wednesday, May 14, I was notified by several of
our PDs of a bulletin from New York Division of
Criminal Justice Services (DCJS) that they had just
received. Dated May 8, it announced that effective
immediately, DCJS is requesting (not requiring, to be
fair) addition of a heavy level of Domestic Violence
data to Uniform Crime and Incident Based reporting.
This kind of stuff demands a lot of new logic, new
data fields, and significant impact on processes and
user viewed layouts... something that can literally
take months to implement in a SQL based system.
Therefore, it imposes quite a burden on the software
vendor, who has to decide if, when, and how to
implement it - since this is not just some new layer
that can get added on top - and to the police
department and its users and/or officers in that all
this new stuff has to be captured and totaled
manually until the software vendor comes up with the
fix (and the likely very large bill attached to it).
I get the "why Filemaker" question a lot, though not as much these days as we used to, since Filemaker embarked on its Platform direction. Here's the best answer yet.
I cursed, swore and complained all day Wednesday and half of Thursday about this. Thursday afternoon I actually read through the whole publication three times. Even though it stems from a single identifiable incident - a dispute in a parking lot, a straight-up domestic dispute at a residence - the reporting itself is actually person (or more accurately in a database context, contact) based, and can involve several persons per incident, though each person can only be assigned one reported value. Got it?
Turns out each reportable entry involves thirty five possible combinations of data in a matrix of five reportable crime generic types and seven types of personal relationships involving the victim (Wife by Husband, Husband by WIfe, Child by Parent, etc). Therefore, what is really required are two base entry fields: one for the crime type and one for the relationship type - and thirty five calculation fields, one for each of the possible thirty five outcomes. Add thirty five summary fields to total the results of those calculations, twelve more summaries to total the sums of all the originals, and one final grand summary to total all values in the lower right corner of the matrix, and you're done, right?
Wrong, of course. You gotta have a way to trigger all this in the first place, to tag an incident as a Domestic, possibly to be reported on. And then, not every Domestic incident is going to rise to the threshold outlined by the five reportable classes, so we need to be able to ignore those. And since we can't just ignore anything without giving rise to the question of was it ignored on purpose or forgotten about, we need some kind of flag to announce that this incident was in fact excluded deliberately. And for data integrity, you should not be able to tag that flag if any reportable information is already attached to the person involved.
And of course there's more... all the process to drive and cause this stuff to happen has to be added, new layouts to display it all need to be written, print routines created, error checking, and don't forget to touch the existing audit trail stuff as well!
Welcome to Filemaker (and twelve years of experience in Filemaker and PolicePro as well, of course - no small thing). Thursday evening it was the whiteboard in the office and a a good part of a legal pad. Friday morning I turned off the phones and hit the office at 7AM. Even with a quick trip to the airport at noon, by 3:30PM I was able to lean back and realize that the entire job was done on the Master file. Now it will be the not insignificant matter of getting it in to the existing client base, since this is not something you just throw on the pile, but the bottom line is that from the initial outrage at this latest bureaucratic insult to a completed and working solution, invisibly integrated within PolicePro like every other part, the whole thing ran two days.
Try that in any other database system and see how you do, even with the logic road map I just presented.
And believe it or not, I actually enjoy doing this stuff! The problem solving is the best part of this whole enterprise... maybe why I enjoyed being a detective so much in the old days.
I get the "why Filemaker" question a lot, though not as much these days as we used to, since Filemaker embarked on its Platform direction. Here's the best answer yet.
I cursed, swore and complained all day Wednesday and half of Thursday about this. Thursday afternoon I actually read through the whole publication three times. Even though it stems from a single identifiable incident - a dispute in a parking lot, a straight-up domestic dispute at a residence - the reporting itself is actually person (or more accurately in a database context, contact) based, and can involve several persons per incident, though each person can only be assigned one reported value. Got it?
Turns out each reportable entry involves thirty five possible combinations of data in a matrix of five reportable crime generic types and seven types of personal relationships involving the victim (Wife by Husband, Husband by WIfe, Child by Parent, etc). Therefore, what is really required are two base entry fields: one for the crime type and one for the relationship type - and thirty five calculation fields, one for each of the possible thirty five outcomes. Add thirty five summary fields to total the results of those calculations, twelve more summaries to total the sums of all the originals, and one final grand summary to total all values in the lower right corner of the matrix, and you're done, right?
Wrong, of course. You gotta have a way to trigger all this in the first place, to tag an incident as a Domestic, possibly to be reported on. And then, not every Domestic incident is going to rise to the threshold outlined by the five reportable classes, so we need to be able to ignore those. And since we can't just ignore anything without giving rise to the question of was it ignored on purpose or forgotten about, we need some kind of flag to announce that this incident was in fact excluded deliberately. And for data integrity, you should not be able to tag that flag if any reportable information is already attached to the person involved.
And of course there's more... all the process to drive and cause this stuff to happen has to be added, new layouts to display it all need to be written, print routines created, error checking, and don't forget to touch the existing audit trail stuff as well!
Welcome to Filemaker (and twelve years of experience in Filemaker and PolicePro as well, of course - no small thing). Thursday evening it was the whiteboard in the office and a a good part of a legal pad. Friday morning I turned off the phones and hit the office at 7AM. Even with a quick trip to the airport at noon, by 3:30PM I was able to lean back and realize that the entire job was done on the Master file. Now it will be the not insignificant matter of getting it in to the existing client base, since this is not something you just throw on the pile, but the bottom line is that from the initial outrage at this latest bureaucratic insult to a completed and working solution, invisibly integrated within PolicePro like every other part, the whole thing ran two days.
Try that in any other database system and see how you do, even with the logic road map I just presented.
And believe it or not, I actually enjoy doing this stuff! The problem solving is the best part of this whole enterprise... maybe why I enjoyed being a detective so much in the old days.
|