Wednesday, April 1, 2009

Individual Interests Need to Support Inclusive Emergency ICT

Here is an exchange today between me and my valued colleague Sheri Ann Farinha, a leading activist for access by deaf and hard of hearing people to the emergency response system. She had circulated the announcement of the new Advanced Emergency Communications Coalition (AECC) on the ListServ “E911 for Deaf and Hard of Hearing”. I commented on why the members of her group should support the broader emergency response ICT agenda represented by AECC, COMCARE’s advocacy successor. I repeat it here because the thoughts apply far beyond the needs of this particular group. Like all email chains, it is in reverse order.


David Aylward



Farinha: Agree with you David, time to work with others and think outside the box to help us find solutions which may or may not be solutions everyone else is needing as well. Esp with the discussion abt the recent independent rate ctrs, smile. Rob said he would be sending me a revised membership form which I will be sure to share with all here once I get it. Thanks for including us with this new network!

De, por, e para, as pessoas!
Sheri~

*****************

Aylward: I hope all the members of this group will also join the Advanced Emergency Communications Coalition (AECC). This is the successor to COMCARE in advocating for all hazards, all emergency domains, interoperable, modern emergency information and communications systems.


COMCARE had devoted attention to both advocacy and efforts to cause specific implementation of our ideas. We have turned over the advocacy to AECC, and will be focusing on the latter: getting Next Generation architecture deployed.


Why do you care when the advocacy is for broader solutions, not just solutions for the deaf and hard of hearing? Because getting where you want to go is very expensive and very slow --the upgrades are only for you, a relatively small percentage of the population, rather than being mainstream. Similarly, the Brain Injury prevention and similar people who care about car crashes, getting that data into the emergency response system, and enriching it with expert protocols, have been frustrated for years. There just aren't enough car crashes to force 9-1-1, EMS and the rest to upgrade to take data in from the outside. Suicide prevention folks? Same thing. And the list goes on.


But if you look at the emergency response system wholistically, persons with disabilities need the same "architecture" and essentially functions as these other uses. A couple of years ago, after detailed conversations with groups such as this, COMCARE held a terrific workshop we called "Common Requirements: Common Solutions" on exactly this topic.


If we are all pulling for the same basic system, we are far more likely to get it, for a lot less. NENA has been very supportive of this approach in its Next Generation policy and technical work.

So join AECC, join with the car crash and other folks, and advocate for common solutions! Rob Martin runs the new group and is a great guy.


***********


Farinha: Dear E9-1-1 Stakeholder Council,

Wish to make you aware of this exciting new Coalition which this Council was asked to have a representative on and attend its first meeting last Wednesday.

Unfortunately there wasn’t an interpreter available at the last minute for me to attend while I was in DC. The information below explains its mission, who, and further information. It’s membership list is being developed, and a press release will soon be going out. Will keep you all posted on new information shared with this network. Patrick Halley/NENA and David Aylward/COMCARE here (who I believe are whom asked for this Council to be

added) are also members of this new Coalition and may have more to add should anyone have questions. :)

---

Advanced Emergency Communications Coalition www.AECCoalition.org <http://www.aeccoalition.org/>

MISSION:

To advocate for the adaption and improvement of advanced emergency communications technologies. WHO WE ARE:

We are an international advocacy organization to promote cohesive and collaborative approaches to improve “end-to-end” emergency communications services and advance public policy and awareness. We encourage the development and availability of potentially lifesaving services, procedures, training, and tools that maximize safety and value for emergency responders and healthcare providers.

BACKGROUND:

Advocating for the improvement of emergency communications services is critical now and in the years ahead as multifaceted, compound issues and choices are being made regarding transitioning all emergency communications services to a new IP-based infrastructure. Global coordination efforts are developing rapidly and all stakeholders need to not only be aware of these efforts, but involved.

By combining the widely diverse membership of more than 100 organizations connected with the COMCARE Emergency Response Alliance, together with other interested stakeholders, the Advanced Emergency Communications Coalition was organized in early 2009 to carry forward COMCARE’s vision of encouraging cooperation across professional, jurisdictional and geographic lines through collaboration with government, the emergency response professions, the public, and private industry.

Coalition members have a strong interest in improving the environment of emergency response and applying modern “next generation” technologies.

Membership includes many leading non-profit organizations, corporations, agencies, and individuals in numerous interconnected industries that impact emergency communications and response. These include, but are not limited

to: telecommunications, emergency management, public safety, first responders, social services, healthcare and medicine, transportation, telematics, government, academia, as well as other groups that have a vested interest in making our communities safer and more secure through the promotion of advanced emergency communications networks and services.

____

Thursday, February 26, 2009

Innovation in Emergency Medical Response

Here is an interesting article about innovation in 9-1-1 response. Sue Hoyt, our former Chairman for many years and former President of the Emergency Nurses Association, brought it to my attention.

Right now, when someone calls 9-1-1 and says they need emergency medical help, we often under resource (do nothing), and more often over resource (send an ambulance), when the situation calls for something in between. The English emergency medical response system began experimenting with using their 1-1-2 (their 9-1-1) system as a gateway to a range of medical services several years ago, using nurses as triage experts. Richmond EMS, led by Jerry Overton, was the first in the US to try it. Now Louisville, Ky and COMCARE member Priority Dispatch are trying it there.

With budgets tightening, and technology making it easy to pull in expert resources, we can expect more pressure for more informed response.


February 22, 2009
Lexington Herald-Leader

Louisville looks to ease emergency room backlogs


Officials in Louisville are looking at a new screening system for 911 calls as a way to reduce overcrowding in emergency rooms and limit ambulance runs.

Metro EMS recently received a $50,000 grant to look into how best to filter out lower priority calls that don't require an ambulance.

Dr. Neal Richmond, director of Metro EMS, said hundreds of ambulances are sent out each year in Louisville to respond to ailments that might not require one. Those calls are taxing the city's emergency response system.
Many of them go to 911 operators either because the patients making the calls have limited health insurance or they have no doctor or one who is unavailable.

"If there's an alternate way to handle 911 calls and get people the care they need, we're all about that," said Debbie Fox with MetroSafe Communications. "It's very innovative."

If the system is enacted, The Courier-Journal reported that 911 calls deemed low priority would be rerouted to a registered nurse, who would determine what care is needed. That could range from recommending treatment at home or making an appointment for the patient to visit a doctor or clinic.

This month, EMS officials talked about potential new software with doctors, nurses, hospital administrators, emergency dispatchers, social service agencies and others.

Greg Scott with Priority Dispatch, the company that developed the software, said only Richmond, Va., has incorporated it fully in the United States. A few other American cities have tried it, and the system is prominent in Britain.

Implementation won't happen overnight. It will take a significant network of resources, including requirements for medical providers to keep appointments open and assistance from transportation companies in providing taxi vouchers or bus rides.

"It's a vast effort," Richmond said.

Steve Heilman, a doctor with Norton Healthcare, said he expects the program could help reduce hospital crowding but warns it will take some education for the public to catch on.

"Community perception is going to be a very difficult area to address,"
he said. "People call 911 expecting to get an ambulance."

Sunday, February 8, 2009

Next Generation Emergency Communications and Cloud Computing

[The following comment was written to a list serv of persons interested in 9-1-1 access and response for persons who are deaf or hard of hearing. I wrote it in response to a notice of an upcoming FCC summit on 9-1-1, and a request for questions for the panel.]

David Aylward, February 6, 2009


The clearly stated emergency communications concerns of the deaf and hard of hearing community (along with those of lots of other constituencies, use cases, etc) will get properly addressed, with a mainstream solution, when and if Next Generation Emergency Communications gets installed everywhere a person calls from, or needs help.


I think a critical question for the FCC to ask at these two safety summits, and all of us to ask and answer, is how system-wide solutions can be deployed rapidly and efficiently, rather than the current excruciatingly slow and expensive method of upgrading PSAP by PSAP, 6500 times over (and the same for every other emergency agency). How can we have the equivalent of a “software upgrade” downloaded to emergency agencies rather than the equivalent of driving out to each office, tearing out custom electronics and replacing them with new equipment on site, which is what we do now, even though it is the most expensive way to do it, whenever each agency can scrape together the money to make a big purchase.


Solving this is not a question of money or technology -- in the first instance (although those are very relevant secondarily). It is first a question of architecture (what is the best way to construct a modern emergency information and communications tech system to meet public needs?), and then of a political governance system (or new business model) to implement that architecture.


The Problem: It has taken 13 years from the date of the E9-1-1 requirement by the FCC to get to a point where at least one PSAP in counties including 90% of the population can accept and display the trivial amount of data required to do automatic location of wireless 91-1 callers: latitude/longitude and call back number. It has been almost 10 years since the time OnStar agreed to send crash data to PSAPs, and not one is getting it today. There are some large, sophisticated PSAPs and emergency response organizations. But the vast majority is small, underfunded organizations, with very limited IT expertise. There are very, very few purchasing aggregations (i.e. buy for a whole state or region all at once). This picture is repeated in the other emergency response agencies (PSAPs being 5-7.5% of the universe), which is a huge problem because NG9-1-1 rests on shared backbones and IT with them. How can we get them and the PSAPs together to get upgrades done?


Do it again is the Solution?? If the solution proposed is repeat the E9-1-1 experience, to upgrade PSAPs one at a time (or in groups of 3-10 at a time) with modern NG 9-1-1 capabilities (which will take care of concerns of this community, crash data and a whole lot more), don’t think you are going to see that any time soon. Right now there is no business or governmental alternative being proposed to the traditional way of doing business for end points (agencies).

There are very positive examples starting of shared networks (e.g. Indiana), although those are still limited only to 9-1-1. So while NENA recognizes the problem, and its NG Partner papers sometimes mention alternatives, NENA is stuck asking for more federal money to spread around to individual PSAPs or groups of them, and there won’t be anything like enough money.


No! Instead, Put your head in the Cloud: Similar problems are solved in the commercial world with software solutions offered from the network. Goes by various names: subscription-based, application service provider, managed services, network-centric solutions, cloud computing. Information technology experts can go on for hours on the differences between those four, but fundamentally they all mean the same thing to folks like us.


If you get them, in your PSAP you don’t have to worry about buying new equipment and new software, and then managing a complex information technology system. You do need to have modern windows computers, earphones and redundant, and secure connections to IP broadband networks (like Brian Rosen talked about here the other day) to plug into the software services – which are hosted remotely (at regional, state or national levels in highly secure, redundant data centers). The PSAP manager needs to worry about training staff and using the new information. S/he no longer worries about systems and upgrades to the software or equipment. R&D innovations are encouraged because now the market is clearly national, and innovations implemented rapidly and cheaply not every couple of years. Competition is enhanced.

The technology to do this is pretty straightforward and well established in the commercial fields and the US military. For it to work in safety, some work needs to be done in key areas (security, what we call “core services”). But the biggest problem in shifting gears to do it this way is the approach and decision making, the architecture/system design and procurement.


Focus on public’s experience, end to end: If we focus on the end points (upgrading the agencies themselves one by one), we will continue to upgrade very, very slowly, and very expensively, repeating the E9-1-1 Trail of Tears on a much larger scale. But we have a good chance of succeeding if either government or private sector leader(s) develop an architecture that treats safety as a “virtual enterprise” (i.e. looks at the overall picture, end to end, from the perspective of the best and least expensive service to the public), and then offers agencies the network-centric, shared services needed to get calls and data to the right places, and the option of subscribing to the best modern safety IT for handling the information delivered to them, managed in top of the line hosting centers.


I am not saying every agency should stop buying and managing its own information and communications technologies. New York City, Washington and LA can and will do whatever they want to do. I am saying that if this remains the sole or predominant approach for all of the tens of thousands of individual organizations in the safety world, we will fail both these agencies and the public.


Right now, I am pessimistic as there is no entity in government taking this broader view, much less working on such an architecture. No agency has been put in charge of the overall emergency information and communications technology issue, the “virtual safety enterprise”. Perhaps more importantly, the companies that serve these markets today are stuck in the traditional sales models, while the companies which can deliver efficient managed services/cloud computing haven’t stumbled on this market yet, probably because it is so fragmented.


But we have new FCC leadership. We have a new Administration, and the recession may push forward thinking IT companies (inside and outside the safety industries) to look for new markets. So hope springs eternal!


I will award a special 9-1-1 coffee mug to the person who does the best job at boiling this down into one or two questions for the summit!

Monday, January 26, 2009

Some Myths and Misunderstandings about Wireless Safety Broadband

January 25, 2009


Myths and misunderstandings surround the discussion of the “D Block”, the proposed creation of a national wireless broadband network for safety agencies and users. Three in particular appear in almost every story or speech on this topic. These misunderstandings are also present in one way or another in most debates over the broader topic of emergency information and communications technology, of which the D Block is only one limited part.


1. Broadband and Internet Protocol will solve the problem”. “Pipes” alone will not solve the emergency response information and communications technology problems. Translating every communication into Internet Protocol won’t cut it. To hear some proponents of broadband, by itself it will reduce medical costs and make us all safer. The national 9-1-1 association, NENA, has the right perspective. It clearly stated in its January 22 letter to Congress that the new broadband stimulus package should not just be transport, but instead ensure that:


“all 9-1-1 centers and emergency response entities have access to broadband networks and the services and applications enabled by such networks. Deploying broadband networks, establishing emergency service inter-networks that utilize such capacity and developing the software applications, information services, and system interfaces required to take advantage of such infrastructure will truly bring emergency communications into the 21st century.” [Emphasis added]


To be sure, the integrated, interoperable emergency communications system needed for our times requires broadband connectivity for the more than 100,000 independent organizations in the US that respond to emergencies (9-1-1 centers, fire services, law enforcement, emergency medical services, transportation departments, public health offices and numerous other support agencies, plus “N-1-1” groups, NGOs like the Red Cross, and a variety of private organizations). We cannot seriously talk about a modern emergency response system unless all these entities are connected to secure IP backbone broadband networks, and ideally have wireless broadband access to extend those capabilities into the field. The traditional focus of first responder communications leaders on voice grade connections will not suffice.


Unfortunately, in the emergency space there has tended to be almost a total focus on transport, generally ignoring the application layer. But merely getting a “fat pipe”, merely getting access to Google and CNN, will not solve the problems of emergency response. Merely connecting all our doctors and emergency organizations to broadband won’t get us interoperable sharing of emergency medical information, including needed parts of electronic personal health records. It won’t get public warnings distributed, or OnStar data delivered usably to the correct 9-1-1 and trauma centers. That doesn't mean transport -- pipes -- is unimportant, but we already have lots of it, in lots of different flavors. Pipes alone can’t move information properly, interoperably in the emergency eco-system. Try playing on the Internet without a browser or domain name server.


As another example, the P25 first responder radio networks being deployed today incorporate broadband IP-based backbone infrastructures and VoIP technology, yet are not commonly capable of interfacing with the Internet or even other P25 networks because they lack the software applications that would support such interoperability.


This imbalance is a very, very big deal because the only way to make rapid progress on inter-domain, inter-jurisdictional, and inter-everything else safety information sharing is to convert every communication into Internet Protocol and then focus on the application layer; focus on what network-centric software things need to happen "in the middle" and with "interfaces from end points to the middle", shifting from focus on the end points (what happens in and at different agencies, or with the devices being carried by their staff). The “transport” focus has meant little to no federal or state government attention and funding of network-centric, application layer solutions and policies – and thus very little progress on overall emergency data interoperability.


2. "A new safety wireless broadband network will solve the interoperability problem." Lack of voice and data interoperability is a huge problem in emergency response. A prominent myth is that the primary reason for creating a wireless broadband access network (or any transport network) is achieving interoperability with other agencies. It doesn't, anymore than building any new network is about interoperability -- unless everyone will be on that network -- which is never going to happen. Right now billions of Federal and State homeland security dollars are being spent to build statewide P-25 radio networks for police and fire (with a national projected cost of over $50 billion to equip just all first responders). However, P-25 is an entirely different air interface than the LTE or WiMax technology likely to be used for a D Block broadband network (for which an additional $15-30 billion is sought). The key to interoperability is getting new and legacy systems (including but not limited to first responder radios) to communicate with each other, not putting everyone on the same network and buying everyone the same radio.


Interoperability is not going to get solved at the transport layer, other than the conversion of communications into IP at gateways. It will be solved first and foremost at the application layer, which IP makes much easier to do. Use whatever radio access works best for you and your agency, but convert the communications to IP with an inexpensive ($1500-$3000) gateway interfacing to a broadband IP safety infrastructure (which could be a combination of dedicated and commercial facilities). Then use the new sophisticated Radio over IP software packages like Cisco’s IPICS and Twisted Pair Solutions’ WAVE to tie it together with my cell phone, and your office wired phone or laptop, Charlie's old VHF police radio with IP, and Susie’s powerful new radio on the statewide P-25 network. And if the device manufacturers (e.g. Nortel, Motorola) will open their APIs, we can make signaling (device control features) interoperable, not just the communications content. The increasing linkage of varied safety agencies: first responders, 9-1-1, local, state and federal agencies to a common broadband infrastructure will provide a foundation for the growth of critical applications and services that will support interoperability.


There are lots of good operability reasons for having safety broadband networks (and P-25 networks); interoperability is not the driver.


3. "A wireless broadband network for responders is critical". Emergency response organizations don't just need a wireless broadband network. They need to be connected to all the broadband networks that are already there: terrestrial fixed (fiber, microwave), wireless and satellite for backup. Why are we only talking about mobile wireless, and focusing only on some of the incident needs of some responders? The primary reason is the balkanization of our decision making in emergency ICT which I have written about at length elsewhere. But even so, this narrow focus is mistaken. The information to be shared over wireless mobile broadband needs to come from and go to lots of places, not just be shared on the wireless link between a dispatch headquarters and its staff in the field. And fixed broadband networks that reach to those other information locations and agencies are already ubiquitous and cheap. Except in a few cases, we don’t have to build new ones; we just need to connect all emergency agencies to the private and public IP networks that exist and provide the network-centric applications that will allow the sharing of information over them (what we call shared and core services). Why are we reversing the model that is so wildly successful in the commercial and consumer spheres (explosive wired internet demand over time created a rapidly growing market for wireless broadband)? Getting organization to organization interexchange of information going over broadband will help create the demand for wireless broadband services for emergency purposes that is so small today.


Moreover, you can't have a regional or national wireless network without a huge wired network underlying it for backhaul and control purposes. Why aren’t the FCC, DHS, and everyone else looking at the synergies from combining these two closely connected, mutually supportive needs? Why is the emphasis only on the access needs of first responders on the scene, and not the need to get information (e.g. building plans) from third party sources to the headquarters so it can be sent out to the field? And what about the information needs (and inputs) of the myriad other organizations (9-1-1, transportation, hospitals, public health, etc.) that are critical in dealing with emergencies, but the primary communications of which are not wireless?


******


We are trying to foster the evolution of modern safety information and communications technology -- from tens of thousands of local, regional, state and federal silos that exist today towards a “virtual safety commons” supporting the exchange of critical information between these parties. We need to learn from the wildly success models of the commercial growth of the internet and wireless.


Start with a lean wired and wireless broadband infrastructure and the first generations of the key network-centric applications with limited capabilities. We should adapt as much of existing commercial transport and software solutions as possible to both speed the process and keep the costs down. For the transport layer, we should incorporate quickly what works from broadband wireless commercial service providers, wired broadband commercial service networks, and existing dedicated state and metropolitan broadband safety, transportation and other networks. At the application layer we should focus on developing and deploying the necessary shared and core services applications – in the middle -- supporting the messaging and data standards we already have.


Once emergency response folks see the benefits of such open architecture, and their masters see the cost benefits, I believe there will be an increasingly rapid development and deployment spiral. It won’t be a perfect network to start, but we don’t know now what the “perfect network" will be. Even if we did, we don’t have the current demand to support it financially, as the FCC and PSST leaders discovered last year when the D Block auction failed. Let’s avoid the tendency to declare we will build the perfect solution and bring in the consultants to spec the system. Doing that will produce a unique, overpriced and out of date solution, as we learned from the DOJ IWN (national network for federal first responders) project disaster. To reach a vision, we need a series of well founded steps with a regular re-charting of the progress to the vision, and sometimes of the vision itself.


Responses, critiques and suggestions are welcomed.


David Aylward

Director

COMCARE Emergency Response Alliance

daylward@comcare.org

Tuesday, December 9, 2008

A Fast, Effective and Efficient Emergency Communications Plan for the Obama Administration


David Aylward[1], December 4, 2008


Introduction

All the key reports on 9/11, Hurricane Katrina, and similar disasters have pointed to failures and weaknesses in emergency communications and information sharing as critical and primary problems. 9-1-1 and emergency communications and response systems remain largely stuck in the technology and mentality of the 20th Century resulting in the loss of life, emergency communications systems that repeatedly underperform and/or fail in major disasters, and overall system inefficiencies. The new Administration will face this one way or another. It can confront the problem as a major national and White House priority – and solve it. A strong, visionary effort by the Obama Administration to deploy next generation emergency communications and information technology will save lives and property, reduce injuries, protect homeland security, improve emergency medical care, and ultimately save money across a wide array of local, state and federal safety and related functions. Such an effort is also wholly consistent and supportive of the emphasis on investment in broadband and critical infrastructure outlined by President-Elect Obama. [2]

Alternatively, the Obama Administration can allow the current Bush programs and policies in a wide variety of agencies to continue. If it does the latter, responses to the emergencies that will inevitably arise in the next few years will be weakened and lives will lost – both in disasters and in daily emergencies. We have failed to make significant progress in all forms of emergency communications since 9/11, despite spending billions of federal dollars. The current morass of emergency communications policy is not due to a lack of emphasis and resources on homeland security at the Federal level; it results from a lack of direction and leadership that understands modern information technology. It results from a failure to treat the emergency communications system as a single, “virtual enterprise”, pursuing instead disjointed and uncoordinated efforts based on different public safety professions and historical perspectives.

The Obama Administration should apply its focus on modern information technology and 21st Century information sharing paradigms to dramatically improving our nation’s emergency communications. 9-1-1 agencies need to be able to receive data and video from the public, not just voice calls, and need to be the nerve center of a smart, all-hazards, Internet-protocol, interoperable and integrated emergency response system. Emergency organizations of all kinds could provide more informed response (and responders would be safer) if they had access to, and could share, video, text messages, car crash data, key personal electronic health data, building plans, extrication guides, traffic information, electronic maps, weather and hazmat data. These are all available electronically somewhere, but usually not to the brave responders who need them. From the first 9-1-1 call at the beginning of an emergency, to the patient’s going home from the hospital, and from the onset of a disaster to the communities’ recovery, we need to give all our responders access to all the information they need, when and where they need it.[3]

· We still lack real voice interoperability for and with the tens of thousands of emergency organizations[4], and data interoperability with almost all of them
· Public warning and alerting is a hodge podge of stove pipe efforts: locally, at the states, by various DHS initiatives, within HHS, DOJ, DOT, Commerce, the FCC, and the private sector
· Inter-organizational data sharing and situational awareness is spotty at the very best
· 9-1-1 can only accept voice calls; text, video and data beyond location and number cannot be received; it cannot send or receive information to or from “N-1-1” entities like 2-1-1 social services, 3-1-1 city services, poison control centers or 800 number crisis hotlines
· Local emergency IT systems rarely connect to private organizations and NGOs involved in emergencies, much less employers and the general public
· The National Guard and other military organizations typically cannot share situational awareness or other information with civilian organizations, unless they are using the same software application, which is usually impractical
· In providing billions of dollars in emergency communications grants to the states and localities, there has been a narrow focus on buying new “transport” (on communications networks and devices), rather than on Internet Protocol and the “application layer”, where both interoperability and information sharing linking legacy systems are far more easily and cheaply accomplished
· In direct federal expenditures for software systems, there has been a dominant focus on buying specific federal software applications and trying to force state and local agencies to use them, rather than providing network-centric tools that enable the linking of diverse legacy applications
· There are no major federal or state efforts to focus on network-centric solutions – what is needed “in the middle” to connect the legacy systems of tens of thousands of emergency organizations
· There are no major government-enabled efforts to establish common standards across all the domains (professions) involved in emergency preparation, response and recovery; the small programs that exist are not seriously funded or given priority; the handful of larger programs are domain-specific
· There are is no common “Yellow Pages” of emergency organizations, enabling routing of incident information to all the organizations in the safety eco-system[5]. Nor are there standards for them (the equivalent of DNS servers for email: .com, .net, .gov etc.); therefore every sender of emergency messages needs to know and keep up to date its own list of the recipient organizations, and how to send data to them, a recipe for incompleteness and inaccuracy
· To ensure security, there is no federated organizational access control and identity management service across all the emergency response domains, or standards for them, to record information rights policies, enabling organizations to know which ones are allowed to send and receive emergency information, or that they are who they say they are[6]; this has to be hard coded, creating silos by agency, jurisdiction or domain
· Huge amounts of local, state and federal money are being wasted on duplicative programs and functions due to the stove-pipe and balkanized approach that has been followed.[7]

Why is this? The primary reason is that traditionally emergency communications decisions have been made at the individual agency level. Whether it is local, state, or federal government, there is no senior official above (and with authority over) the individual agencies and professions in charge of the big picture of emergency communications. There is no senior federal or state official responsible for emergency communications and information technology, with the responsibility and budget to bring a coherent “virtual safety enterprise” analysis and architecture to the problem. No senior official is asking and demanding answers to the overall key questions, or insisting on overall systemic outcomes and efficiencies (as opposed to improving the functioning of single agencies or single professions).

There is no emergency response Chief Technology Officer. No one is looking at the total cost of ownership of emergency information and communications technology for the federal government, much less federal, state, local and tribal. If they did, they would insist on shared applications that would produce overall benefits. No one is demanding true “all-hazards” planning, design, and implementation. (DHS is mostly focused on intelligence and law enforcement; to the extent it does emergencies it forgets health, and only does disasters; HHS only does health IT, but not emergencies except a bit for disasters, and a lot for some participants in pandemics; DOJ only does intelligence and crime; DOT does traffic information, EMS standards, and a smidgen of 9-1-1; most state and local agencies focus on day to day emergencies; so-called state “interoperability committees” were formed to rationalize the expenditure of federal funds on new digital police and fire radio systems).

Despite tough talk from the Bush Administration about the importance of emergency, interoperable communications, no one in the White House or OMB ever exercised serious overall leadership, demanding a common vision, coordination and cooperation. The “e-gov initiatives” supposedly managed by OMB included two emergency information and communications technology (ICT) projects: Safecom and Disaster Management[8]. Neither ever attempted a comprehensive, inclusive view. Individual agencies addressed these issues for themselves in a piecemeal way. There are at least 17 separate programs within DHS, scattered through several divisions that claim to be addressing some of the above issues.[9] None are trying to address all of them. Staff who try to take an overall view, to contribute to the whole, have been shut down. DHS, Congress, the FCC and others have not effectively addressed the problems for jurisdictional, interest group and leading safety vendor reasons.

And what about the transition to the new Administration? Issues concerning emergency information, communications technology and information sharing are most likely mentioned, perhaps highlighted, in transition reports from teams covering DHS, HHS (HRSA and CDC), the FCC, and even the Corporation for Public Broadcasting. These issues could just as well be part of reports for DOJ, DOT, DoE, DOD (including National Guard), and DoA, as all five of those departments have emergency ICT issues, programs, and/or requirements. But these issues cannot be properly addressed within those individual boxes, even if within each agency they were perfectly coordinated. Agencies and program staff understandably resist taking on projects beyond their boundaries and they have little incentive to do so.

Suggested Action Plan

Summary of Expected Outcomes, Action Items and Key Principles

The Obama Administration should not follow the failed models of the past. It should:

· Recognize that solutions to these issues are the compelling safety reasons and uses for the broadband deployments President-elect Obama has committed to encourage
· Make emergency communications a signature challenge and project for Administration, leading from the top, including the new overall CTO
· Recognize there are tangible day-to-day and disaster safety improvements that can be delivered to the public in the near future as we work toward a fully integrated, interoperable emergency response and communications system. The latter will take a long time and a lot of hard work, but early successes will speed adoption
· See how at a time of enormous demands on government budgets at all levels, better communications and information technology can be delivered at less cost, following the path that the commercial sector has blazed
· Harness and redirect projects already underway and undertake new ones to make rapid, tangible progress on emergency communications, with clear benefits to both the public and emergency responders.

Expected Outcomes

In the first 18 months the Plan should:

· Deliver rapidly an all-hazards, all levels of government and the private sector, public alert and warning system linking all outlets to the public, enabling them with the multi-use core services discussed below[10]
· Deliver rapidly a handful of other high value, high profile shared, managed information services, enhancing informed emergency response and situational awareness, and pointing the way toward an exciting, safer future. Two of these should be:
o Rapid, flexible and inexpensive voice interoperability through the use of software
o Rapid, inexpensive situational awareness for all authorized organizations
· Enable the above with the development of, and standardization of, two key shared “core services”[11] required to enable interoperability over the entire safety enterprise:
o Who are the participants? Agency locator/GIS-based registry of organizations involved in emergencies needed for sharing of information before, during, and after emergencies of all magnitudes among local, state, federal and private entities responsible for emergency response
o Security. Access control/identity rights management and related security services where the above referenced organizations are registered and given appropriate authorizations to send and receive emergency information

Action Items

· Assemble immediately a team of paid and unpaid experts who can deliver the broad-based policy, technical, operational, political and economic planning needed to accomplish these suggestions
· Assemble all the mentioned federal agencies into a federal team with a designated White House leader, with OMB support, and the clout to require cooperation
· Assemble a working group of the above and leaders of state and local agencies, leaders of the affected professions (see two bullets down), NGOs, and relevant private sector leaders; this group needs to be well populated with experts without a corporate or specific constituency “axe to grind”
· Approach emergency response overall, as an end-to-end system, focused on outcomes for citizens, under all hazards, and on overall costs and benefits, rather than as a collection of discrete response professions (e.g. police, 9-1-1), emergency problems (e.g. nuclear, pandemic) or specific communications methods (e.g. P-25 statewide radio network, wireless broadband)
· Define safety/emergency response broadly and inclusively as an overall “virtual enterprise”. Require planning and Total Cost of Ownership analysis according to this enterprise and with all the participants at the table. This should include the traditional first responder professions (police, fire, EMS), other emergency response professions, agencies and NGOs (e.g. 9-1-1, emergency management, hospitals/trauma centers, public health, Red Cross, poison control, mental health, and other “N-1-1” entities), government emergency support professions (e.g. transportation, public works, IT, schools), critical infrastructure providers, the media (especially public broadcasting), and other relevant participants (e.g. the Chamber of Commerce). It should include both wired and wireless communications, with a heavy emphasis on Internet Protocol software based solutions (the “Application Layer”) that link legacy systems, instead of buying all new systems
· Require recipients of federal funding to implement a broad, inclusive definition of “interoperability,” beyond traditional voice radio interoperability restricted to “first responders”, which definition advances interoperability of voice, data and video communications among all entities involved in emergency response. Similarly legislation should allow funds to be used not just for “equipment”, but also “software and services”, allowing the use of shared IP-based emergency service networks and services
· Establish an inter-agency working group to coordinate the distribution process and eligibility criteria of all sources of Federal funding for 9-1-1 and emergency communications
· Provide funding for the shared IP emergency communications backbones and associated services in each state and/or region needed by 9-1-1 and all other emergency entities to support Next Generation emergency communications; coordinate this backbone need with the ongoing development of a national 700 MHz public safety broadband wireless network currently being planned by the FCC
· Initiate Total Cost of Ownership thinking and analysis for this virtual enterprise – where federal money is involved, require planning decisions as if there is a single owner; the public will benefit
· Involve citizen groups that respond to end to end, citizen-focused approaches, including the American Heart Association, Brain Injury Association, American Automobile Association
· Involve the organizations that represent individual responders, not just the agency chiefs: Emergency Nurses Association, EMTs, firefighters, FOP for example
· Adopt “everything over Internet Protocol” and open architecture requirements
· Significantly broaden the narrow focus on buying new networks to achieve interoperability, and generally on communications “pipes” (the “Transport Layer”)[12]
· Add a major focus on the Application Layer, and specifically on managed, shared services that do not require capital investment or sophisticated IT staffing by the mostly small emergency agencies
· Provide major support for the creation of data dictionary, messaging and other standards serving the whole virtual safety enterprise, not just parts of it – by those safety professions[13]
· Rather than trying to upgrade the tens of thousands of individual agencies, which has been proven to be horrendously slow and expensive[14], focus on the “middle”, the network-centric applications that can enable more informed, interoperable and situationally-aware response[15]
· While the above is going forward, launch on a parallel track a “Solutions Delivery” Project charged with delivering broadly useful, interoperable (and interoperability-enabling) solutions rapidly, in part to show the value of this approach to the public and the other affected constituencies. These solutions need to be delivered over large enough regions or uses to have an impact on current thinking. In the future, most of these services should be self-supporting through subscriptions from the public and private sectors. The government should cost share for the development and deployment of these components, bear the initial cost of developing the policies (business rules) at all levels of government to use them, and train staff to use them.

Emergency Communications Solutions Delivery Project

This will seek to implement the agenda described above. It is designed to successfully and efficiently address in 18 months a handful of salient emergency communications issues. It is designed to (a) enable initial interoperability between legacy systems, (b) address the “bottom end” of the market (those agencies, organizations and persons with the least resources), (c) encourage cooperation and information sharing between appropriate entities, and (d) provide software tools, but leave policies and information sharing decision making in the hands of the appropriate levels of local, state, tribal and/or federal government. In all cases, the elements must be standards-based and fit in an open architecture so that solutions can freely interact with applications and networks controlled by other entities. It will include the following elements:

Agency and Consumer Software Services and Applications

· Interactive alerting/public warning. Today there are a multiplicity of use-built, stove pipe warning systems, and we are adding to them[16]. We need to link these legacy systems, not replace them. The way to do that is with common message standards and shared core services, not building new systems or stand alone products. We need to be able to reach the public and vice versa both through social networks of all kinds, and more formally through established agencies, services and businesses. We need to connect official sources of any hazard, any area alerting to any and all systems of communication in use by the public[17], and offer the public at least one attractive messaging service for personal emergency use as well as communications to and from government entities[18]
· Map-based, web-based emergency message generator and receiver application for budget-challenged and volunteer emergency organizations [19]
· Public information distribution after initial alerts, taking advantage of the trusted and ubiquitous public broadcasting system and all its digital assets as both part of the initial alerting process, and then afterwards as a public destination and distribution system for information

Shared Services[20]

· Voice communications interoperability, using sophisticated software to link dynamically any kind of wireless and wireline communications to any other kind of communications,[21] supported and enabled by core services
· Family emergency preparedness: intensive communications of the content already developed by ready.gov and leading partners such as Sesame Workshop[22]
Simple situational awareness, using incident and related information delivered to a locally-specific electronic map[23]

Enabling Services (“Core Services”) [24]

· Develop and standardize[25] the key shared “core services” that will allow efficient interoperability over the entire safety enterprise, helping connect networks and applications into what an FCC report called an “internetwork”[26]:
o Agency locator/GIS-based registry of organizations involved in emergencies[27]
o Access control/identity rights management and related security services[28]

· Provide funding to develop best practices for registering organizations and rights management policies[29] in the core services, and having legacy messaging and RoIP systems interact with them

· Provide and host middleware for intelligent message brokering, security, and auditing of compliance with access control and other rules.[30]

The above applications and services need to be hosted and offered as managed services on a subscription basis. They need to be managed in secure, reliable and sophisticated platforms that also offer agency customers service and billing functions. Appropriate subscription fees can and should be charged.[31] Each of these components must be architecturally independent so any application using the designated standards can be interoperable with them. Each will be able to initiate and process information using the DHS-sponsored international OASIS CAP and OASIS EDXL family of emergency messaging standards[32], along with other standardized data dictionaries and forms (e.g. National Information Exchange Model). Organizations receiving federal emergency funds should not be forced to use any of them. They should be free to use legacy systems and acquire new ones of their choosing, as long as they:

· Convert voice and data communications to the outside world into Internet Protocol[33]
· Connected redundantly to Internet Protocol networks, ideally backbone networks shared with other emergency organizations
· Ensure their legacy and new applications and systems interface to these standards.[34]




[1] David Aylward is a founder and Director of COMCARE Emergency Response Alliance (www.comcare.org), President of National Strategies, Inc., and a former Chief Counsel and Staff Director of the US House Subcommittee on Telecommunications, Consumer Protection and Finance. He has worked on emergency response issues for more than a decade. daylward@comcare.org. This paper is a living document; comments are welcome.
[2] This paper draws heavily on the analysis and near term suggestions for progress made in an article prepared by the author and the former Inspector General of DHS, Clark Ervin. See Clark Kent Ervin and David K. Aylward, “Next-Generation Inter-Organizational Emergency Communications,” Aspen Institute (sponsored by the Ford Foundation), December 2006, http://www.aspeninstitute.org/atf/cf/%7BDEB6F227-659B-4EC8-8F84-8DF23CA704F5%7D/Homeland_InteroperabilityReport.pdf
[3] A short video at www.comcare.org/video.html provides a vision of how emergency medical response could work if enabled in this fashion. Unlike the faster progress described in this paper for public alerting and warning, and a few other capabilities, that vision is achievable in the medium term (3-4 years).
[4] There are about 120,000 independent emergency response and response support organizations in the United States, not counting more than 100,000 schools, and other NGOs and businesses that are involved in emergencies.
[5] The FCC’s Network Reliability and Interoperability Council VII’s 1D Report called for these “Facilitation Services” to be established several years ago. This paper and others now call these “Core Services”.
[6] See footnote 5.
[7] Aside from safety and security benefits, an extremely interesting study would compare the Total Cost of Ownership to local, state, tribal and federal governments of the current siloed systems under the control of their multiplicity of masters, with the TCO of a modern efficient system based on Internet Protocol where backbone networks, enterprise services, and other appropriate functions and costs were shared, while customer premise applications were required to communicate externally using standard messages.
[8] The author’s organization, COMCARE, was a contractor to Disaster Management for two years, helping develop standards for communicating data between the diversity of emergency organizations.
[9] See, e.g., DNDO (CBRNE), S&T UICDS, S&T SAFECOM, S&T Disaster Management (now renamed), S&T assorted emergency response ICT projects, FEMA IPAWS, FEMA Office of Communications, FEMA OPEN project, FEMA Interoperable Emergency Communications Grants Program, FEMA CEDAP, FEMA NIMS, Homeland Security Information Network, State Homeland Security Program (SHSP), Urban Areas Security Initiative (UASI), Metropolitan Medical Response System (MMRS), Citizen Corps Program (CCP), CIO’s NIEM.
[10] These are described in some detail in the Aspen Institute article cited in footnote 2.
[11] These were strongly recommended in 2006 by the FCC’s Network Reliability and Interoperability Council VII 1d report, see http://www.nric.org/. The need for these core services has been noted by a variety of emergency organizations and papers. See, e.g. HHS’ Health Information Technology Standards Process (HITSP) Interoperability Specification 4; NENA Next Generation 9-1-1 paper, 2007; Network-centric Operations Industry Consortium Network-Enabled Emergency Response Project papers. See also, www.comcare.org/Core_Services.html. COMCARE has done a great deal of requirements work with all the emergency professions for core services over the last several years. It has produced detailed functional and technical requirements, and designs that meet them. As yet, no IT company has built an alpha version to allow a standardization process for them developed by the Open Geospatial Consortium and COMCARE to proceed.
[12] See the COMCARE blog article by the author, “Why Doesn’t the Government Get Emergency IT?”, September, 2008, for an exploration of this issue. http://comcare-talk.blogspot.com/. Certainly operability is an important issue, but it is not the only one. And certainly there are some agencies which are not close to and/or cannot afford wired broadband connections, but those are in a small minority.
[13] There are a number of standards efforts, but they have all been either entirely underfunded or stovepipes (one or only a few emergency domains), or both. The largest is the AHIC/HITSP effort funded by HHS to develop standards for electronic health records. It includes, but is not focused on, emergencies. DHS never gave the money or direction to the National Information Exchange Model (NIEM) to become more than an adoption of the pre-existing, longstanding justice community taxonomy efforts. The DHS Disaster Management Program got off to a positive start gathering all emergency responder professions around a table to develop detailed draft common messaging standards, a number of which are now official OASIS international standards. But it has been given little funding and has produced no additional standards output in almost three years.
[14] Consider the 14 year “Trail of Tears” to upgrade 9-1-1 centers to receive a tiny amount of data along with wireless calls: latitude/longitude and call back number. Around 20% of the centers, covering around 30% of the land mass, still cannot receive that data.
[15] The US military has a long and deep history in the area of network-centric information technology operations. Faced with a new requirement for the military (regular and Guard) to be interoperable with civilian organizations in the US and abroad to allow assistance in complex human disasters, leading military contractors are exploring how to help US emergency agencies solve these problems. See the Network-centric Operations Industry Consortium’s (NCOIC) Network-centric Enabled Emergency Response project which is focused on core services.
[16] For example, the WARN Act has agencies establishing a one way alert capability that will use public broadcasting infrastructure only to get to stations and cell companies, only to deliver to cell phones, only up to 90 character text messages, and only for Presidential alerts, “life threatening” emergencies, and “Amber alerts”. There is nothing wrong with that use case and pathway conceptually as a component of a comprehensive system, but that is not how it is being constructed.
[17] All these systems need to be able to register for this purpose in the agency locator core service, and have their authority to send and receive messages about different kinds of incidents over different geographic areas registered in the access control core service.
[18] This is the messaging equivalent of using 9-1-1 for cell phones. The government will benefit if it has large audiences of private users it can reach in emergencies, and if systems such as these have a standardized way of accessing government services, including but not limited to 9-1-1.
[19] The functional requirement here is simple. We need to allow any authorized organization to initiate and receive a message concerning a specific incident type and a specific location or area of any size, using the OASIS EDXL Distribution Element or OASIS Common Alerting Protocol. If the DE is used, it can carry a digital payload of any standard, not just OASIS messages.
[20] “Shared services” are (generally managed) services shared between multiple, but not all, emergency domains.
[21] See http://www.comcare.org/RoIP.html. Cisco, Twisted Pair Solutions, and others have commercial software that does this.
[22] Grover and Rosita are the stars of an excellent new DVD-based package developed by Sesame Workshop that teaches kids of all ages (including very young ones) and their parents how to prepare for disasters. It was announced in September, 2008, but has not received wide circulation.
[23] The fastest, cheapest approach to common situational awareness is to share incident and related data about the affected area on a web-based map. For those agencies with limited resources the mapping need not be expensive. One state has taken the lead in this area using Google Maps. See “Virtual Alabama”. Maryland has pursued a higher end, non-incident, proprietary version of this idea with the GIS company ESRI; its acronym is MEGAN.
[24] These are managed, standardized services offered to all emergency domains.
[25] The Open GeoSpatial Consortium, supported by COMCARE, has developed a detailed plan to do exactly this: in an open, inclusive process develop standards for the content and querying of the two core services described here. It awaits a leading company to build and test the first alpha versions of core services meeting the developed requirements.
[26] See FCC Network Reliability and Interoperability Council VII, Report of Group 1d, 2005, www.nric.org.
[27] COMCARE has undertaken years of functional and technical requirements development resulting in a detailed design for the agency locator registry, called “EPAD”, and detailed technical and design requirements for the companion access control/identity management core service . www.comcare.org/epad
[28] See www.comcare.org/core_services.html.
[29] Core services do not make rights policies; they simply provide a software application in which to record those policies and implement them efficiently. The rules themselves are made by the appropriate body for the incident type and geographic area.
[30] This is a possible use for the new version of FEMA’s OPEN message broker that is being redesigned now.
[31] The point is not to preclude customer premises software, but to create managed service options so that high quality information technology is available to all emergency organizations, even those that lack the budget and expertise to buy their own software and manage it.
[32] For complete versions of the standards, see http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency. FEMA’s Disaster Management Program funded the process that developed the detailed specifications for these standards. It was subsequently shifted to DHS’ Science and Technology Directorate which also has some other, uncoordinated standards efforts (e.g. a “CAD to CAD” project of some justice and 9-1-1 agencies).
[33] Modems are relatively inexpensive; many agencies already have them.
[34] This is not a new idea. Federal DHS, DOJ and DHS grantees are already required to acquire software that can interface with their various standards.

Tuesday, December 2, 2008

Broadband: Necessary but Not Nearly Sufficient

David K. Aylward

Today a wonderful cross section of folks who care about communications will come together to announce a National Broadband Strategy Call to Action. It is a terrific and important undertaking. Indeed, since at least the summer of 2001, COMCARE has actively advocated ensuring for all emergency organizations what we had earlier done for the schools: connecting them all to broadband. We must start with "everything over IP." So we strongly support this initiative led by our friends at the New America Foundation and others.

The paper that will be handed out today references the benefits of broadband to public safety and health care, among a list of other areas. In much more detail, Bob Litan did a presentation last month on the health care benefits that are possible if we can get medicine into the digital information sharing age. His focus as well was on the need to deploy broadband. Throughout 2008, the FCC has worked to try to figure out how to get wireless broadband to safety agencies. Certainly organizations cannot begin to take advantage of the increasingly rich information environment in which they sit without it, much less share that information with other entities and any staff in the field.

It is also true that broadband is necessary but not nearly sufficient. Hooking up 6500 9-1-1 centers and 30,000 EMS and fire agencies to broadband does very little on its own. Almost every hospital has broadband today, but information sharing with other parties is minimal.

Unlike individuals, to get the benefits of electronic information sharing in the broad, diverse and highly balkanized safety area, we need an equal (if not greater) focus on the application layer, on software and related issues. Earlier this fall I spent some time ruminating on why it is that in our policy debates (and indeed our policies) there is an almost singular focus on communications and broadband (the transport layer), and little to none on the information technology, the software.

Those thoughts are in my September posting which I have updated a bit. This seemed like a good time to underline those thoughts again.

Friday, September 26, 2008

Why Doesn't Government Get Emergency IT?

Why Doesn’t Government Get Emergency IT?

David Aylward, September 26, 2008

Achieving integrated and interoperable emergency response systems requires that the participants connect at the transport layer (communications pipes connect) and at the application layer (simplistically, software and its interactions). (For purposes of clarity of discussion, I am simplifying to two layers in the stack).

For the past several years, in the emergency space there has tended to be a very strong focus on the transport layer, almost ignoring the application layer. This translates into "building interoperable emergency networks and systems" as opposed to "linking legacy systems with software." The first is very expensive, and can't be the solution anyway as all the relevant organizations are never going to all be on the same network, using the same radios. But yet we continue to pour billions of dollars into building new pipes, while starving the application side.

In industry terms (again simplistically), we have been choosing the telecommunications industry over the information technology industry.

The commercial and military worlds are way, way ahead of what I call the "virtual safety enterprise". They are well down the road towards network-centric operations, cloud computing, managed services, service oriented architectures, and the like.

This imbalance is a very, very big deal because the only way to make rapid progress on inter-domain, inter-jurisdictional, and inter-everything else safety information sharing is to focus on the application layer: convert every communication into Internet Protocol and focus on what needs to happen "in the middle" and with "interfaces to the middle" instead of the end points (what happens in and at different agencies). (That doesn't mean transport is unimportant, but we already have lots of it, in lots of different flavors. My argument is not to ignore it, but to have balance.)

I have been ruminating on why we have this imbalance. Why do so many in the Executive Branch, the FCC, and emergency response communities make this choice, focusing almost solely on transport: in talking, writing, policy making and grant making?

It struck me that the answer is in our history since around 1978.

"Communications" has been under the purview of government for a long time. Information technology mostly grew up outside of government (DARPA aside). So people in government in this area learned communications; IT has been a side show.

I grew up professionally with a Congress and FCC that focused on wired and wireless pipes. All our discussions and debates were about the pipes. The great battles of the 1970s and 1980s over competition were about competition in telephony. In the late 1970s, in the Computer II decision, the FCC explicitly declined to regulate information technology, information services. Those were "those other things". From time to time it has drawn the same line deeper and deeper.

And until recently, the IT industry was very happy to grow up in California and elsewhere and not have to go to fundraisers for Congressmen every night.

"Public safety" at the FCC for decades has meant (almost solely) spectrum for radios for first responders. Thus, we have witnessed a great debate in and around the FCC this year about developing an "interoperable wireless broadband network for public safety." (It seems to have escaped the attention of many that safety agencies don't exchange much data today, much less with the field, much less amounts of data that require broadband.) Almost every time a reporter writes on the topic or a Congressman addresses it, they note it will be a solution to the first responder interoperability problem. Little to no attention has been paid to the critical application layer issues that would allow data to start flowing between agencies on the broad band networks that already exist. Nor has the government made a top priority the application layer issues needed to link legacy radio and wired networks to each other, much less to the new P-25 digital trunked radio systems that billions of our tax dollars are being spent for, much less this new broadband network if and when it gets built. (But kudos to the small progress being made due to grassroots leadership).

The FCC isn't just regulatory. It controls large amounts of money. It recently announced it was spending over $400 million of the Universal Service Fund on rural medical networks -- every one of which was mostly new transport capacity.

When DHS was formed and initially reached out to the traditional first responder community, not surprisingly it got the same communications-focused answers. Its policies ever since have reflected this. Billions of dollars are being spent directly and through the states and localities to buy new emergency networks (mostly radio); a few tens of millions have been spent on application layer issues (and mostly on end point, or area specific, applications, which should not be a priority).

The National Telecommunications and Information Administration at the Department of Commerce is about communications and spectrum. So when Congress handed it the lead role on the special $1 billion in "interoperability grants", what did it do? It let those one time dollars be spent almost entirely to buy new radio networks. After major lobbying, software solutions were allowed and cost/benefit analysis would have required them, but NTIA had no stomach for that. This was in part because it does not have a great deal of IT expertise, and that is because it doesn't have real IT jurisdiction.

The safety market is relatively small, and so balkanized in its decison making and purchasing (120,000+ individual agencies), that it is not an easy market to crack. Nor are the individual domains (EMS, 9-1-1, fire, police, transportation, emergency management) calling for integrated emergency information services amongst all of them. Nor can I find anyone in power in government taking that overall view. After all, as discussed above, most of those in government have communications training and responsibilities. Federal budgets and programs are about communications. The government IT people are generally elsewhere.

So it has been simple for the big IT players, who now have large DC presences, to mostly ignore the safety market.

If Google, Yahoo, Microsoft or their ilk took on the safety market, treated it like a virtual enterprise, and developed standards-based managed application layer services for it, could they cause huge leaps forward in service to the public in emergencies large and small (and major overall cost savings)? Absolutely. Could they make a pile of money breaking down the wall between the public and emergency response (e.g. making sure my health records stored at Google were available to 9-1-1, EMS and the trauma center when I get hurt). You bet.

But from their perspective, sacrificing the small submarket today and a larger potential future one are cheap prices to pay to avoid the federal world the telcos have to inhabit. Plus they have a lot of other things to do.