Will Open Source Come to the Rescue?

Over the past months we have heard about how free and open source software (FOSS) is becoming more and more acceptable in the business community. There has also been a movement to have governments adopt policies that open the door to FOSS. However, it appears that the open source community has overlooked one vital area of the community that would most likely embrace FOSS with open arms, and that is the area of emergency services (Police, Fire and Emergency Medical Services). .

Like any government agency, emergency service agencies need the basic office software, but they also need 'specialized' software, such as Computer Aided Dispatch (CAD) systems, 9-1-1 Call Taking systems, incident reporting systems, etc. Today, almost without exception, every agency is forced to use a proprietary, closed source Windows program. Far too often it is purchased from a company that is no longer in business five years after the purchase, resulting in the need to purchase a replacement product from another vendor. Lastly, because the software is proprietary, the agencies that are able to purchase it cannot do everything they want or need the software to do, nor can they modify it to meet their needs.

The current availability of FOSS for emergency services is extremely limited. As part of a very quick, non-scientific study, we did a search on the Sourceforge web site for software that is geared towards emergency services. We chose Sourceforge as they host 78,324 projects (as of 25 March 2004), all of them open source (They also host our recently started open source project, PAD Program Management). We did a search under four terms; "ambulance," "emergency," "fire," and "police." We only found 20 projects (<>

As an EMT/Paramedic for over 20 years, I have seen computers make their way into the field, frequently with mixed results. The current proprietary software options are often very limited and very expensive, making it inaccessible to many small and volunteer departments (which serve the majority of the country). This relative high cost has a very real effect on the communities served.

Consider the dilemma faced by a small EMS agency that has five ambulances, of which two are staffed by paramedics. As a medical director, do I purchase a high dollar software program to allow my medics to electronically enter an incident report, or do I purchase a new EKG monitor-defibrillator (a machine that looks at the heart's rhythm and can deliver an electrical charge to a quivering heart)? You can almost be assured that the defibrillator will be purchased each and every time.

The problem is by not having a low cost software option, billing accuracy will likely suffer resulting in loss of income. I can't easily look at the response data that will tell me where and how my units are being used, so I can't go to the local town council to lobby for an additional ambulance or funding for training. I can't easily tell where my medics are having deficiencies in their ability to provide care. I can't do a simple query to have all chest pain charts reviewed, instead I have to review every paper report to first see if it is a chest pain incident, then set those on the side to be reviewed later. All of this is a long, tedious, labor intensive effort.

The emergency service community is currently at the mercy of the proprietary software firms. This has an impact far more reaching than the limited scenario outlined above. Another impact area is the inability of emergency service agencies to share data. Let me offer an insight into this problem by sharing my experiences with a program I am working on.

Currently I am assisting another paramedic who is tracking Public Access to Defibrillation (PAD) programs for a large metropolitan area. In a PAD program, an office building, school, work place, or other public area has had Automated Defibrillators (AEDs) installed. AEDs are used by the lay public to help victims of sudden cardiac arrest, prior to the arrival of EMS. Because of their ease of use and rapid accessibility, areas that have installed AEDs and have used them within 5 minutes of collapse of the victim have seen successful resuscitation rates as high as 50% (AHA "Heartsaver AED for the Lay Rescuer and First Responder," page 1-8). They are a probably the single greatest improvement in emergency health care since the advent of EMS.

AEDs have an onboard computer that is able to analyze the victims EKG, and provide the electrical shock if needed. The computer provides voice prompts to the user on when to start and stop CPR. It also records the EKG, the time an analyzation was performed and what rhythm was recognized by the computer, the times of the voice prompts, etc. Also, it keeps a record of each time the unit performed its own internal diagnostic check, the time the machine was turned on, as well as turned off, and more. All of this information is available to the oversight agency by simply downloading the information from the AED's internal memory into a software program/database.

As part of a community PAD program, there is usually legislation that mandates a specific government agency provide oversight to the program. This agency will typically have to track where AEDS are located, how often they are used, and how well they are working. This oversight agency typically cannot dictate to the individual purchaser which vendor they must utilize when buying the AED. In an area such as the one I work in, you may have well over a dozen vendors selling their machines to schools, businesses, public transportation authorities, local and federal government agencies, etc.

Here is where the problem comes in. Each of these vendors has their own proprietary software. None of the software is compatible with any other vendor's software. Further there are no common standards to export the data. If you are responsible for monitoring a PAD program in your community, you may have six, eight, ten or more software programs in which to download AED information, of which none can exchange information. The result is the inability to tell just how well your PAD program is working. You have plenty of data, but you can't use it the way the you want.

The FOSS community has been very good at developing open standards for other items of hardware and software. There is no doubt that the same could be done here, if the FOSS community were to get involved.

I firmly believe that the FOSS community is missing a golden opportunity by not getting involved with the emergency service community. Imagine a FOSS distribution geared towards EMS, Fire or Police Departments. In addition to the typical programs such as KDE, Gnome, Open Office, MySQL, and Apache, there would be a Departmental Database that tracked personnel and equipment within the agency, a Fire Incident Reporting System based on the National Fire Service Incident Reporting System (NFIRS) standard, an EMS incident and billing system, a training database, etc. Is this really that much different from many of the business distributions that it cannot be accomplished?

In conclusion, by working with the emergency service community, the FOSS community would provide a service that is truly valuable to their local community. Open standards would allow efficient data collection and sharing, resulting in improved responses to the local community. Money saved from high priced, proprietary software could then be used to purchase protective equipment for those who provide the front line service, and life saving equipment for paramedics to use could be purchased. This would be an area that the FOSS community could publicize as a true, tangible benefit to using Open Source Software in the local community. There is little to nothing the closed source, proprietary software companies could say in rebuttal.

My hope is that soon there will be the start a dialog of the 'movers and shakers' in the FOSS community who see the value in working with emergency services community. Will open source come to the rescue of emergency services? Only time will tell.

About the Author
Robert W. Austin is a Nationally Registered Paramedic and has been serving in the District of Columbia Fire and EMS Department for 16 years, and has nearly 25 years of fire and EMS experience. He current works as a Paramedic Evaluator in the Continuous Quality Improvement unit, and has been involved in many technology and research projects conducted by the department. He has been involved in developing computer programs since he developed his first program for the Surfside Beach Fire Department on a Commodore 64.