[MRIC] Re: ICS-213 message form
BrettHam at aol.com
BrettHam at aol.com
Sat Apr 21 00:30:31 EDT 2007
Pat,
I had already read the email you sent earlier today before I sent my email
to you.
In my opinion, the form we have been discussing does not significantly vary
from FEMA ICS-213, and is almost identical to NFES ICS-213 and especially
NOAA ICS-213.
We will vote on this during the MRIC meeting Saturday. If you think the form
should be changed, please come prepared to make a motion for whatever
changes you think should be made and we will vote on that as well.
We practiced with this ICS-213 (or variation thereof) during the February
COMMEX; we discussed it at length at the February MRIC meeting; we have had 2
more drills to practice using it and working out kinks; and we have discussed
it at length for the past 2 months via this email reflector. There is no
excuse for anyone not being prepared to vote tomorrow. The alternative is that it
will not get adopted until next year, and I said a long time ago, that is
not an option.
Brett Hammond
Chairman, MRIC
In a message dated 4/20/2007 11:49:37 P.M. Eastern Daylight Time,
wb0egr at comcast.net writes:
Brett,
I suggest that you read the e-mail I sent to the group at 1735 hours 20
April 2007. This e-mail contains information I received today from
DHS/FEMA pertaining to ICS-213.
If you remember, at our Feb 24, 2007, meeting, I suggested that we
obtain guidance from an official source about the ICS-213 form; however,
my suggestion was dismissed.
If this means a postponement of the vote on the ICS-213 to a later date,
then so be it. We do want this done correctly to be compliant with
DHS/FEMA and the Presidential Directive from the United States White
House which began the interoperability process which includes the
ICS-213 General Message Form.
Pat, wb0egr
BrettHam at aol.com wrote:
> Pat,
>
> Are you suggesting, now, less than 12 hours before we vote, that you are
now
> saying that the ICS-213 form that we have just spent the past 3 months
> reviewing and refining is not acceptable?
>
> Brett Hammond
> Chairman, MRIC
>
>
> In a message dated 4/20/2007 11:01:01 P.M. Eastern Daylight Time,
> wb0egr at comcast.net writes:
> All,
>
> Because we are potentially dealing with a wide variety of Agencies,
> including Federal & military, DHS/FEMA guidance must be followed or else
> the jurisdictions that support us face the very real possibility of
> losing Federal Funding in the form of Grants, etc., should changes be
> made to the ICS-213 endorsed by FEMA.
>
> Hence, with all due respect to W3YRS and the ARRL, etc., their input on
> the ICS-213 is not relevant in this matter.
>
> 73,
> Pat Scolla, wb0egr
> Harford County EC & RO
>
> Fred K3CSX wrote:
>
>> The following is feedback from one of our DRO's that I wanted to share
>> with the group. It was written just before the most recent version was
>> distributed by Al W3YRS on 4/17.
>>
>> 73, Fred.
>>
>> ------------------------------------------------------------------------
>>
>> It's always an uphill battle getting people to completely fill out
>> message forms, and in my experience, a losing battle. But that doesn't
>> mean that we shouldn't try. A well-designed form will facilitate
>> compliance; a poorly-designed form will discourage compliance.
>>
>> 1. It is hard to get people to record the ICS position of the
>> sender/addressee. That is vital in a long-term event, because the person
>> occupying a given position will change over time, and you may have
>> people from other agencies rotating into positions so the name is not
>> easily recognized. You need to have the ICS position or title to
>> interpret and respond to the message. Having a separate block for that
>> information makes it more obvious that the form hasn't been completely
>> filled out.
>>
>> 2. Having the reply on the same message form works if the message is
>> hand-delivered (e.g., within the EOC), where the recipient can scribble
>> the response on the bottom of the form and send it back. If the message
>> is to be transmitted via radio, the reply is a completely separate
>> transaction, and should be recorded on a separate form. It helps to
>> include a field in the message header: "In reference to message number
>> xx." This helps to sort the messages for post-exercise analysis.
>>
>> 3. Assuring unique message serial numbers is difficult when multiple
>> communications channels are flowing. One solution is to use forms that
>> are pre-serialized. A more general solution is to use a date-time stamp.
>> Neiter of these approaches work particularly well. See below for a third
>> approach that works marginally better.
>>
>> 4. If you use a separate form for replies (as recommended above), is
>> provides more space at the bottom of the form for recording tracking
>> information. In addition to knowing the date and time the message was
>> created, it helps to document how the message was routed (via courier,
>> RACES 2M/440, telephone, etc.), who the message was delivered to
>> (addressee, relay station, etc.), and the time of delivery.
>>
>> 5. Date format of yyyymmdd is more conducive to automated sorting---
>> useful for post-exercise analysis. However, if they manage to write the
>> date and time in any legible format, I'd be ecstatic. It needs to be
>> clear whether you are talking about the time of origination, time of
>> transmission, or time of delivery. All are important.
>>
>> 6. I have participated in numerous debates about the wisdom of a
>> including a field for message precedence on the form. Everyone thinks
>> their messsage is urgent, Moreover, since they don't necessarily know
>> what messages other folks are sending at any given point in time, so
>> they don't have a basis for deciding the relative importance of their
>> message relative to the others.
>>
>> Message precedence is only important when there is a backlog of messages
>> waiting to be processed. What works better in that situation, I think,
>> is to leave precedence off the form and assign a communications officer
>> who is familiar with the operation to look at all pending messages and
>> queue them for transmission. If the radio operator is experienced
>> enough, they can do this job. If the radio operator doesn't have the big
>> picture, this should be a separate assignment.
>>
>> My philosophy, when there is a backlog, is first in/first out, unless
>> there is a message of obvious importance that needs to be placed at the
>> front of the queue. Otherwise, the lowest precedence messages can
>> languish for very long periods of time. If the backlog becomes severe,
>> the communcations officer had best be arranging for an additional
>> communications path, rather than wasting time juggling messages.
>>
>> 7. You don't need the name of the incident on the form. Sure, there
>> could be a situation where we are running two incidents simultaneously.
>> It should be pretty obvious what incident is being referred to, and you
>> don't want to give people writer's cramp. If it's not obvious, the
>> message isn't very well-written.
>>
>> 8. The subject line is a nice feature, but with hand-written messages,
>> generally unnecessary. In email, it is possible to sort messages by
>> subject, a handy feature to quickly pick out all the messages in a
>> thread. Also, with email, you can look down a list of message subjects
>> and pick out the ones that are most "interesting" (ignoring the rest, of
>> course!). For hand-written messages, having a separate subject line
>> contributes to writer's cramp and slows down transmission.
>>
>> 9. I like the idea of having a check box to indicate when the message is
>> an exercise message. This helps to remind the radio operator to say,
>> "This is an exercise message." I vividly recall an exercise where
>> someone (fortunately, not one of the hams) transmitted a message
>> reporting fatalities without indicating that this was an exercise
>> message, generating a half-dozen calls to 911 from people with scanners
>> wanting to know if they needed to take cover. (Unfortunately, no one had
>> told the call-takers that there was an exercise going on, so they were
>> pretty freaked out until a supervisor sorted things out.)
>>
>>
>> Attached is a format meeting most of the criteria discussed above. This
>> image was from the 1987 edition of the Montgomery County RACES/ARES
>> manual. We (RACES) helped MCEM design the form. It had just enough
>> information to be able to tell what happened, without being unduly
>> burdensome for users. The County went to a commercial printer who
>> printed a large quantity of message pads with 2-part carbonless copies.
>> The originator kept a copy, and the recipient or radio operator retained
>> the original after disposition.
>>
>> Note that the radio operator assigned the message number and also
>> recorded the path (e.g., 2M, 800 MHz, etc). Messages that were hand-
>> delivered don't require a message number. The stack of originals (for
>> messages sent) and copies (for messages received) at a given radio
>> position constituted the log of messages handled by that position. There
>> was no need to create a separate log. At the end of the incident, all
>> message forms were collected for subsequent analysis. Beause the
>> operator initialed the form, if you had a question about the disposition
>> of a given message, you would know who to ask for clarification.
>>
>> This form was more successful than most I worked with, because it was
>> simple and easy, but fairly comprehensive. Transmission was facilitated
>> because the message structure was standardized. We decided not to
>> include the message check field because virtually all of our message
>> traffic was on full-quieting FM channels.
>>
>> In real incidents, we didn't use very many message forms, because we
>> always tried to arrange it so that we could hand the mic to the
>> operations person at each end and let them talk directly to each other.
>> It was always our goal to get out of the message business and be a
>> switchboard instead (plugging people together who need to communicate).
>> The forms were used mostly for taking messages when one of the parties
>> couldn't be reached.
>>
>> In the real world, most communications are too complex to reduced to two
>> or three sentences on a form. There needs to be a discussion to explain
>> the background and the nuances of whatever issue is being addressed, and
>> ideally, some give and take between the parties.
>>
>> Fortunately, real disasters evolve over a period of hours or days.
>> You're not trying to cram the whole enchilada into a two-hour exercise,
>> so there is time for the operator to find the person you need to talk to
>> and bring them to the radio, or better yet, bring the radio to them.
>>
>> If the person isn't available to talk and you need to leave a message,
>> there is usually an aide, or pehaps someone who sits next to the person
>> in the EOC, who has some understanding of context. So you don't need to
>> write the message down verbatim in that situation. You simply say,
>> "Please tell Janet blah, blah, blah," and they write down the salient
>> information.
>>
>> Formal written traffic is only required in those instances where the
>> messenger lacks the experience and/or context to correctly relay the
>> message, and you need to spell it out precisely. That's actually a
>> fairly unusual situation in disaster response---but it's exactly that
>> situation that requires the form we are talking about.
>> ________________________________________________________________________
>>
>> Fred Bader (K3CSX) Post Office Box 2993
>> mailto:k3csx at arrl.net Gaithersburg, MD 20886-2993
>> ARRL Life Member Montgomery County (FM-19)
>> ______________________________________________________________
************************************** See what's free at http://www.aol.com.
More information about the MRIC
mailing list