OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency] Public as responders (was RE: [emergency]...PPW letter re CAP)


I've seen two issues. One that deals with asset management where a "first
responder" is a member of the general public. If the only electronic asset
at a scene is a cell phone (or PDA) you may have voice, text messaging
and/or picture taking capability (GPS with a PDA). You need to be able to
identify and classify the asset. Will you accommodate communications to that
asset? The question is not if you will communicate with the asset if it's
held by an EMT, just whether or not you will consider a cell phone or PDA an
asset and provide communications to/through the asset.

There is a person holding the cell phone who is also an asset. If you choose
to use that person you need to quickly classify their capabilities and
provide information to emergency management on the capabilities of the
asset. The data path to the human asset may be through a dispatcher,
directly to their cell phone, VOIP, etc. The path doesn't change how the
asset is used, just how the asset receives information.

The other issue seems to be around broadcast media or the general public
receiving and providing information. This still feels like asset management.
If the media or citizens who own bullhorns, CB radios or digital cameras are
assets then the asset should be added to the available on-scene (or
available) assets. The emergency management team then has to decide if and
how the asset will be used, including the path for the information. If a
video clip or picture is considered essential to the management team then
the bandwidth will be consumed - this isn't a standards issue, it's an asset
management decision. 

*Allowing* a video clip or digital picture to be communicated electronically
seems essential in an EM standard (I think the suggestion was that this can
be accommodated by adding a single element). Identifying assets and their
attributes is essential. Identifying a path or multiple paths to/from an
asset is essential. How an asset is used in an emergency situation is not a
standards issue.

gary

-----Original Message-----
From: Art Botterell [mailto:acb@incident.com]
Sent: Wednesday, October 08, 2003 7:08 PM
To: emergency@lists.oasis-open.org
Subject: RE: [emergency] Public as responders (was RE: [emergency]...PPW
letter re CAP)


[This thread might seem a bit off-topic but I suspect it may have 
Infrastructure implications, as well as illustrating one reason we 
can't always draw the circle as tightly around our Messaging 
applications as a first glance might suggest.]

Claude -

Absolutely, dispatch centers should be included in any overall 
emergency information model... although I can report from experience 
that only in theory is there merely a one-way flow (call for service) 
from public to officialdom... the reality is more complicated, as 
most any 9-1-1 recording will illustrate.

That said, I know that NENA is interested in  standards for data 
flows between Computer Aided Dispatch centers.  So is APCO and I 
believe it's also a theme in the IEEE 1512 program.  And, of course, 
in the JXDD.  Also, the ComCARE Alliance is involved in some very 
advanced work on the dissemination of incident information, both 
among response agencies and to and from official responders in the 
field.

But my point was that a lot of the lifesaving response in a disaster 
doesn't involve 9-1-1 or any officially-designated responders at 
all... that's one of the ways disasters are different from day-to-day 
public-safety response (although the role of civilian bystanders is 
significant in a lot of "routine" incidents, too.)  So sharing 
information with the public isn't just a matter of directing their 
aggregate behaviors... it's also important in supporting the 
large-scale "people helping people" processes that takes up the slack 
during a disaster response.

- Art



At 4:06 PM -0500 10/8/03, Bullard, Claude L (Len) wrote:
>Then the Dispatch/911 system should be involved.  There
>are various approaches to this but they aren't a matter
>of notification of the public, but of the public notifying
>the Dispatch center.  A question of some importance would be
>what kind of notification is the public responder giving
>to the Dispatch operator, eg, a Call For Service?  How
>to classify the notification and queue the response is
>more difficult than working out the technology for getting
>the image from a cell phone into the CFS records.  My guess
>is that a survey of existing 911 Dispatch systems would
>reveal that many could do that.  It would be reasonably
>straightforward, for example, to provide a public access
>version of our web products that would enable the public
>to do that, but as you say, the administrative problems
>would be difficult.  It is more likely that a call to
>the dispatcher would get resources dispatched quicker,
>but that an ability to store and forward on the scene
>digital media files could be created for intel purposes.
>
>len

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgro
up.php.


******************************************************************************
The information in this email is confidential and may be legally
privileged.  Access to this email by anyone other than the
intended addressee is unauthorized.  If you are not the intended
recipient of this message, any review, disclosure, copying,
distribution, retention, or any action taken or omitted to be taken
in reliance on it is prohibited and may be unlawful.  If you are not
the intended recipient, please reply to or forward a copy of this
message to the sender and delete the message, any attachments,
and any copies thereof from your system.
******************************************************************************



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]