Can We Go Wrong in Creating Public Safety Communications Standards?
This year’s APCO show was great, and got me thinking a lot about technical standards and their place in public safety. Between NENA’s recent approval as a ANSI recognized standards body, a large number of standards in process through APCO, and the huge investment made in P25, standards are a hot topic across 9-1-1 and public safety as a whole. Interoperability is key, and without standards that becomes a nearly impossible undertaking. If tying each application together is a custom project, the spider web of connections between solutions becomes untenable. A single change has a ripple effect across internal and external systems that is often unforeseen and always expensive to correct. Allowing the proliferation of proprietary systems without paying proper attention to interoperability is not unique to the public safety industry, and the pitfalls are well known. Taking a quick look at the video industry is a great example.
But… we have to be careful to balance a standardized outcome against a standardized way of achieving an outcome. Sometimes we have a tendency to think standardization is the answer to all our woes and those of us creating the standards know how best to accomplish a goal, not just establish what that goal should be. Allowing ourselves to be standards “happy” can have a detrimental effect on an industry. To understand where we can go wrong in creating standards, let’s start by looking at the benefits of a standard. Whether it be a technical standard or a operational one, there are really three big reasons a standard is critical
1) Interoperability – This is all about allowing different systems (or even people) to “talk” to one another effectively. It establishes a common language that disparate but interconnected systems both understand.
2) Portability – This is moving from one way of doing business to another. It might mean switching CAD systems, and ensuring that the call history can be easily moved from one to another. It minimizes the cost of change.
3) Liability protection – This is really about implementing best practices and having the “backing” of a body of experts in helping you define your processes and operations.
So, how can a standard be bad? As soon as we get into the business of dictating how someone achieves a standard we risk stifling innovation and increasing costs. Consider a young student. Ideally we teach them the subject matter in whatever way works best for their learning style, and then measure their comprehension through a “standardized” test. The idea is to measure the outcome, not the how. As soon as we get into dictating a certain way a subject has to be taught we hamstring the teacher’s creativity, frustrate the students that struggle with that learning method, and probably stifle the ones that are quick learners.
What does that have to do with public safety? I think we sometimes think we should create standards that dictate the how and not the outcome. Let’s focus on ensuring that we achieve the goal of interoperability and portability between systems. We’ve got a long way to go to get that done. None of us can predict where innovation with go, and if we get into dictating how vendors or agencies will functionally accomplish their mission we will force stagnation and never improve. Those entities that step “outside the box” to make a seed change improvement will be penalized because they didn’t stick to the standard (or lowest common denominator in some cases). Standards and interoperability benefit both vendors and public safety officials and are critical to our overall mission of improving public safety. We all put a lot of time into developing and adhering to them, so the tendency to “over-engineer” them is a natural one, but one we really have to resist.
How does this relate to operational standards? The importance of standard protocols and call handling in 9-1-1 can’t be overstated; however, some of the same issues described above for technical standards also exist for operational ones. In a fluid, and rapidly changing environment it is very difficult for standards to keep pace when they are extremely rigid. The introduction of new communication types and integrating new sources of data into the call handling and dispatch process should not be impeded by standards processes, but instead strengthened by it. Again, there is a fine line between over-scripting the how versus ensuring interoperability, portability, and liability protection in defining key steps which MUST be accomplished and those that MAY be taken.