[MRIC] Re: ICS-213 message form

Sat Apr 21 07:25:37 EDT 2007

I made a grave error in my e-mail last night that I sent out at 2059 
hours.  I got Al Nollmeyer's callsign wrong.  I must first apologize to 
Al, W3YRS, by mentioning him in this e-mail. I meant to write:  W3YVQ. 

Thus, I meant to write:  Hence, with all due respect to W3YVQ and the 
ARRL, etc., their input on the ICS-213 is not relevant in this matter.

Again, my apologies to all and especially to Al, W3YRS.

Sincerely,
Pat Scolla, WB0EGR

Pat Scolla wrote:
> 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
>>
>>
>>   
>
>
> ______________________________________________________________
> 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
>
>