This is a feedback assignment designed to give you an incentive to practice and acquire skills and give you feedback
before you use those skills in the large assignment and the midterm. It is not a summative assessment of a learning module. You will learn BY doing the assignment.
I do NOT encourage let alone insist that investigators find “THE” CAUSE. Just producing a clear description of an event can lead them to a set of information that will meet the quality criteria: comprehensive, unbiased, reliable,
and useful – enable them to develop interventions. Factors can be causally relevant without being “the” cause or even possible to prevent. Factors can be actions or characteristics of people that contributed without being errors.
Diagramming is a valuable method to document the information you have and organize it so that you can see the
relationships among contributing factors and find potential paths to prevention.
This assignment:
o Identify a personal story that happened to you or someone close to you that you know pretty much everything about. It may have resulted in personal injury to you, them, or others, or property damage or other loss.
o It will include one or more errors. Multiple errors may have been independent of each other, or an error may have been a failed reaction to the result of a previous error.
o You will diagram all the contributing factors – events and conditions – and their relationship to each other and the outcome(s).
o You will identify the error(s), and identify the type of error. You should use the error typology in the notes and explain why that is the best match for the type.
o You must be correct for slip, mistake, lapse. You should try to be close in the sub-types. If you cannot classify sub-types, it may tell you that your diagram lacks the context that would enable you to select a
sub-classification.
o Diagram the flow of events primarily horizontally, with the outcome at the LEFT margin, with antecedents to the right of the effects. Antecedents of effects include exceptional conditions and events and unexceptional conditions (i.e., design features and procedures) and events that contributed to or enabled the injury-producing collision.
Note that a cause-consequence tree diagram needs to include implied requirements when documenting a contributing deviation (e.g., suppose you consider “the cloth was wet” to be a contributing deviation, you should also document “the cloth is required to be dry”) otherwise it is unclear why the factor is relevant. Likewise, an action (or non-action) is only an error if a different action (or non-action) was required. The requirement should be
recorded so that documentation of the error makes sense.
In addition to the logical arrangement of the above facts, the following requirements must be consistently fulfilled.
The point will not be earned if the requirement is inconsistently fulfilled. Use this document as a checklist!
o Use software such as Microsoft Visio or OmniGraffle for Mac. Visio is available in the OPH computer lab.
DO NOT produce your diagram by HAND or using word processor boxes
o Use rectangular boxes for the events, with all boxes the same size
o Format the size of the boxes and the text inside the boxes so that all of the text fits within the box (you
may need to use abbreviated phrasing – the full statement corresponding to that “shorthand” can be
produced as a companion document for the diagram).
o Put connection “magnets” on the East and West ends of the box only
o Use orthogonal connectors with arrows pointing toward the effect and curve the corners of the
connectors (important!) (I use 20-degree curves on corners as these are visually distinct from corners of
boxes.)
o Arrange boxes to eliminate crossed connector lines
o Minimize the number of bends in connectors (e.g., in most cases no more than 2 bends per line) and align
boxes neatly
o Fill the boxes that represent Errors with a yellow tint. You will list these separately (another document)
and identify the error types using the code, and explanation of the choice.
Welcome to Legit Writing
