[MRIC] Re: ICS-213 message form
Pat Scolla
wb0egr at comcast.net
Fri Apr 20 23:48:49 EDT 2007
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)
>> ______________________________________________________________
>> This email list is for the use of RACES Officers and Emergency Managers.
>>
> Only email related to the Maryland RACES Interoperabilty Committee (MRIC) of
> the Maryland Emergency Management Association should be sent to this email
> reflector list. All emails must be in plain text format (no HTML).
>
>> MRIC mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/mric
>> Help: http://mailman.qth.net/mmmain.htm
>> Post: mailto:MRIC at mailman.qth.net
>>
>>
>>
>>
>
>
>
>
> ************************************** See what's free at http://www.aol.com.
> ______________________________________________________________
> This email list is for the use of RACES Officers and Emergency Managers. Only email related to the Maryland RACES Interoperabilty Committee (MRIC) of the Maryland Emergency Management Association should be sent to this email reflector list. All emails must be in plain text format (no HTML).
> MRIC mailing list
> Home: http://mailman.qth.net/mailman/listinfo/mric
> Help: http://mailman.qth.net/mmmain.htm
> Post: mailto:MRIC at mailman.qth.net
>
>
>
More information about the MRIC
mailing list