[MRIC] Re: ICS-213 message form
Dan Blasberg
ka8ypy at verizon.net
Sat Apr 21 01:01:51 EDT 2007
Brett,
I find the tone of your reply a little discouraging to say the least.
It comes off as approve this form or else. Well, I have a question, or
else what? The agenda is for this year is not written in stone
anywhere, if it was and agreed to before the first meeting, then it was
done so foolishly.
My OEM Director went to the same 1st Responder Summit this past week,
that Joe went to, and his question posed to me in an e-mail I just read
after getting home from work at midnight.
Will the modifications we are making to the ICS-213 for the state of MD
be accepted and approved by the NIMS Integration Center?
The idea here is to use the same form for all large scale incidents.
No offense to anyone that doesn't boarder another state, but my
jurisdiction boarders two of them (I know, DC Is not a state). My EOM
Director was fine with the proposed changes until he went to the
summit. He got essentially the same answer there that Pat and his OEM
Director got from the NIMS Integration Center.
"Almost identical" is not sufficient, if MEMA can not answer yes to the
question of the modifications being accepted and approved by the NIMS
Integration Center, then both myself and my Director have serious
reservations about supporting the modifications and will use the stock
FEMA ICS-213.
Dan Blasberg
KA8YPY
Prince George's County RACES RO
Prince George's County ARES EC
On Apr 21, 2007, at 12:30 AM, BrettHam at aol.com wrote:
> 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.
> ______________________________________________________________
> 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