Cognizant 20-20 Insights

Improving the Efficacy of

Root Cause Analysis
Medical device organizations must act rapidly and effectively
when addressing product, process and system nonconformities.
By following our framework and applying a relevant and appropriate
level of automation to root cause analysis, they can ensure swift
action while avoiding issue reoccurrence.

Executive Summary
In the medical device industry, a top mandate is
getting it right the first time, especially when it
comes to addressing product, process and system
nonconformities. In the last decade, regulatory
bodies such as the U.S. Food & Drug Administration
have issued warning letters highlighting the need
to effectively handle nonconformities in their
effort to maintain the effectiveness and safety
of medical device products in the market. In
response, medical device organizations are under
pressure to develop an approach that results in
quick and non-repeatable closure. Doing so will
also benefit the business, as it can boost market
share, revenue, profits and customer satisfaction,
as well as minimize product recalls.
To ensure a permanent fix, nonconformities
must be scrutinized meticulously to ward off
future occurrences in both the current product,
process or system, as well as in similar product
lines, processes, quality systems and even operational locations in the organization.

cognizant 20-20 insights | april 2016

Root cause analysis (RCA), therefore, has

become a high priority for medical device
organizations that want to ensure zero
reoccurrence, especially for Class II and III
devices, in which nonconformance issues
could be life-threatening to patients. Although
automated RCA tools do exist, RCA is still
typically performed manually due to treatment
variations from case to case. Organizations also
struggle to select the right tools and use them
in the right sequence, and are prone to jumping
to conclusions without following or anticipating
the needed steps.
This paper discusses the key steps of an effective
RCA process (see Figure 1, next page), the appropriate tools and the sequence in which they
should be used. We also identify best practices
identified in our RCA experience. It should also
be noted that high-quality input information is
essential to developing an effective RCA.

The Process of Root Cause Analysis

This diagram illustrates the key steps in an ideal RCA process, as well as the appropriate set of tools and optimal
sequence of use.

Flow

Clarify
Problem

Grasp
Situation

Collect
Causes

Narrowing Down to Root Cause

Typical Tools

Initial problem statement/perception

Pareto,
histogram,
check sheets

SMART defined
problem

5-Whys/1-How,
SIPOC diagram,
fishbone diagram

Locate stages where

problem can occur
and be detected

Gemba, Gembutsu, Genjitsu

Possible
causes

Brainstorming, fishbone diagram,

fault tree, relations diagram,
Johari Window analysis

Effectiveness
Verifications

Experimental testing, physical trials,

risk analysis tools

Cause
Validation

Cause
Analysis

Standardize

Potential
causes

Cause analysis tool, design of experiments

approach, hypothesis testing, paired
comparison, product/process search, affinity
diagram, histogram, Pareto

5-Whys Analysis

Actions

Root
Cause(s)

Figure 1

Every medical device organization deals with nonconformities or problems (issues or complaints)
that need to be acted upon quickly and effectively. The input sources of these problems can
include customer complaints, returned products,
in-house rejections, monitoring trends, nonconformity reports, etc. Such inputs may or may not
include sufficient information for performing an
RCA; its vital for the team to gather complete and
relevant information to build a strong foundation
for successful analysis.
At a very high level, nonconformities can be categorized according to their level of severity, in
terms of regulatory norms, risk to human life,
brand reputation, customer demand, etc. (see
Figure 2, next page).
The problem statement should be framed in a way
that answers the basic questions of what, when
and where the loss in performance or nonconformity was observed. Further, to avoid ambiguity,
it should specify (when possible) the feature
that has failed and the source of the specification (drawing, process sheet, etc.). For example,
if the reason for a rejected component is high
thickness of parts, then it can be recorded as,
Part thickness not within specified limits (51
mm) at supporting ribs, while being produced at
Machine A in Q2, 2016. Any tooling and other

cognizant 20-20 insights

supporting details worth mentioning can also be

included. This way, the RCA team will study both
the chances of thickness being as high as 6 mm,
as well as future possibilities of thickness lower
than 4 mm.
When stating the problem measurement response
(i.e., the attribute or variable), attempts should
be made to convert the attribute response into a
variable response. When a problem seems to be
a combination of two or more problems, opportunities should be found to treat each of them
as an individual stream for study. Statistical
methods such as Pareto charts1 and histograms2
should be used, as applicable. At the problem
clarification stage, it is important to understand
what the source is saying but no need to explain
the problem exhaustively. In fact, causes and
suggestive actions should not be part of the
problem statement.

Grasping the Situation:

The What, Not the Why
When stating the problem, the RCA team should
avoid asking why and instead begin gathering
artifacts that help reveal the source of the
problem. To do this, we recommend using the
3G lean practices of gemba (the real place),
gembutsu (the real thing) and genjitsu (the real

Varying Levels of Issue Severity

High Severity

Low Severity

Key Characteristics

Examples

Examples

Key Characteristics

Life or
business risk

Immediate
corrective
action needed

Generated
from trends

Only immediate
monitoring
expected

Regulatory

May be top priority

Internal logs

Many cases have

historical data

May not have

all complaint details

Selected for
improvement

Many cases
have all
complaint details

Problem occurrence
out of reach

Warranty returns

Problem occurrence
reachable for trials

Customer
complaints

Threat to
organizations
reputation

Figure 2

data).3 This should be done as close as possible

to the time of the problem occurrence, with the
intent of collecting multiple observations from
the actual site where the problem occurred.

can also be identified by monitoring the problem

from a wider viewpoint (different time spans, fault
sources, locations, etc.) and identifying variations
in these parameters.

These artifacts and observations will form the

quality inputs for the cause analysis step. The
information (documents, machine and human
remembrance) should be cross-checked for
accuracy to eliminate perception or observation
gaps. When possible, secondary sources should
be checked to calibrate or verify reported and
collected information. When information varies
from source to source, such discrepancies should
be noted as input for the next stage.

Significant variation should be considered as a contributor to the problem. In Figure 4 (next page), for
example, data collected over a two-month observation period clearly shows that all machines are
creating cracked parts, meaning that no specific
machine is causing the defect. Observing the crack
zone variations, meanwhile, suggests the RCA
team should further investigate what is leading
to cracks at specific areas: the supporting ribs
and screw holes. Possible causes could be found
by comparing metallurgical differences, assembly
processes, tooling used, etc. at each crack zone.

When collecting the above observations, the team

should plot SIPOC4 and process flow diagrams,
and represent possible stages at which problems
or nonconformance can occur, as well as the last
stage it will get detected. This will help prioritize
efforts and determine the scope of study.
Figure 3 (next page) shows how drilling down into
affected areas (the highlighted zone) for further
investigation saves effort by eliminating non-relevant areas.

Collecting Possible Causes

Possible causes can emanate from multiple
sources, including the actual details captured in
the problem statement and situation observation.
All the observed causes should be considered
for the purpose of validation. Possible causes
cognizant 20-20 insights

Another fruitful way to collect possible causes is

brainstorming by cross-functional teams (CFT).
With this approach, its important to keep the
focus on the quantity of causes rather than their
quality. Everyone should be encouraged to think
creatively, and all suggestions should be accepted
without debate or criticism.
By using a complete process flow diagram
that shows all suspected sources of incoming
variations for each process, the team can identify
the sources considered as possible causes.
When collecting causes, the team should ensure
complete clarity to avoid later misinterpretation.

Using a SIPOC Diagram to Increase Efficiency

SIPOC

Supplier

Step 1

Step 2

Step 3

...........

Customer

FIRST-LEVEL
PROCESS FLOW
Shows higher
level of
process steps

DETAILED
PROCESS FLOW
Shows greater
detail (documents,
inspections,
re-work flows)

Figure 3

For example, rather than just saying human error,

malfunction or improper procedure, the team
should record the type of human error or malfunction, or what was improper about the procedure.
For causes related to methods, procedures, work
instructions, statements of procedure, etc., the
use of Johari Window analysis5 can help identify
inadequacies, lack of adherence, communication
gaps, training needs, etc. Techniques such as a
preliminary hazard analysis (PHA),6 fault tree
analysis (FTA)7 and hazard and operability studies
(HAZOP)8 can also accelerate the generation of
possible causes.

Validating the Cause

After exhausting all options for collecting
possible causes, the RCA team should validate

each possible cause that has a sufficient or justifiable sample size. The validation process must be
chosen carefully to distinguish perceived causes
from those that are potentially creating the
problem or nonconformity. If reliable data exists
to validate a cause, it should be added to the list
of potential causes.
The cause validation technique will vary based
on factors like testing type (destructive vs. nondestructive), time required, amount of disruption
to the existing setup, etc. It is usually carried out
at the actual failure location or through its representative field exercise, using a lab setup and statistical tools. Validation is performed by creating
a situation in which the cause is acting at an outof-specification value, keeping other contributing
parameters constant.

Identifying Possible Causes by Observing Variations

Number of cracked parts per crack zone (in 2 months)

Number of cracked parts by machine (in 2 months)

18
25

16
16

14

20

12
10

12

12

15
15

8
6

22

10
5

At supporting At screw
ribs
holes

Machine A Machine B Machine C Machine D

Figure 4

cognizant 20-20 insights

At center
of part

At sharp
corners

For example, when studying the failure of a short

molding in a plastic component, the cross-functional team might identify causes such as a low
injection temperature or low hydraulic pressure.
In this scenario, the RCA team should conduct a
validation that maintains injection temperature
and hydraulic pressure (one at a time) at values
lower than their specification limit, while ensuring
other process parameters are kept constant. If the
collected data shows short molding parts being
produced under these conditions, then these can
be seen as potential causes.
The potential causes should then be checked in
a hazard or risk analysis tool such as ReliaSofts
xFMEA or HACCP.9 If the control set of any of
the causes is strong, and the cause also shows
very low occurrence, then those causes can be
eliminated from further study, perhaps after
verifying the adherence levels of those controls
at the design or process level. Causes that exhibit
poor control, high occurrence or no detection
mechanism should be assigned high priority. In
short, cross-checking with xFMEA or HACCP can
help decide which causes should be prioritized or
skipped in further studies.

Analyzing the Cause

Once a list of potential causes has been
prepared, its time for analysis. A cause analysis
tool (see Figure 5) can help determine whether
a cause is properly defined for conducting a
5-Whys analysis or needs to be revisited.10 If the
potential cause lacks specification, or the specification is poorly justified, the nonconformance
issue may not be resolved.

If a cause shows no variation in the collected data,

the team can conclude that its not contributing
to the nonconformity and can be eliminated from
further study. Causes that are properly specified,
are derived from a justified basis and show
variation in the monitored data should be analyzed
in further detail, as these factors are all prerequisites for carrying out the 5-Whys analysis.
The cause analysis step uses multiple statistical
tools to form conclusions with high confidence
levels while minimizing guesses or dependence
on expert advice. Use of Shainin problem-solving techniques, such as product/process search,
component search, paired comparison and full
factorial experiments, will lead to a simplified
way of concluding whether problems are caused
by a process or component.11 Using the design of
experiments (DOE) approach, meanwhile, will help
narrow down parameters or mixes of parameters
that are leading to nonconformance.12
Certain prerequisites should be considered, such
as sufficient data volumes and tool applicability,
based on the situation. The tools mentioned above
should be used by individuals with the proper
expertise, experience or guidance. When using
templates or tools, their underlying assumptions
and limitations should be understood. For example,
a Pareto analysis is often applicable when all events
or factors have occurred and exhibit low severity,
and theres a need to prioritize them (i.e., 80%
of the problems are due to 20% of the causes).
However, this approach is not recommended for
causes, as they must be targeted for 100% elimination. Cases of nonconformity with high severity
may not be a case for Pareto.

Using a Tool to Analyze Causes

Cause analysis tools can help determine whether causes are properly defined for conducting a 5-Whys analysis.
Is there
Is there a
justifiable basis
specification for
to derive the
the cause?
specification?

Is the
specification
monitored?

Is monitoring
Is there any
performed with
variation in
an appropriate
monitored data?
sampling plan?

Action Plan

No

Derive specification

Yes

No

Establish justifiable basis

Yes

Yes

No

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

No

This is not cause

Yes

Yes

Yes

Yes

Yes

Perform 5-Whys analysis

on this cause

Begin monitoring

Figure 5

cognizant 20-20 insights

Derive appropriate sampling plan and begin monitoring accordingly

5-Whys Analysis

Action
Effectiveness

Effective zone to
reach feasible root
cause

Number of Times Why Asked

Figure 6

5-Whys Analysis
At this point, the team will have generated a set of
causes that must go through a complete 5-Whys
analysis to determine root cause (see Figure 6).
When a cause or sub-cause has two or more
sub-causes, the use of a legged 5-Whys analysis
is encouraged (see Figure 7). This will avoid a
force-fit or biased root cause determination.
The best way to verify a 5-Whys exercise is to
validate it in the reverse order of tracing causes
for the problem under study.

Most importantly, if human error is determined

as the root cause during the 5-Whys analysis, the
team should drill down further to identify the
human causes for the error, such as unawareness
or a difficult or cumbersome task. Figure 8 (next
page) lists examples of deeper causes of human
error.
Human error causes, such as forgot to perform
and repetitive work, may lead to actions such
as process/operation automation, poka-yoke or
Kaizen.13 Meanwhile, root causes such as no
procedure or lack of training may lead to inef-

Drilling Down into a 5-Whys Results

Functional
failure

Problem
Why (Potential Cause)

Part missing
in assembly

Why

Part fallen
after fitment

Part not
fitted

Why

Loose fitment
of lugs

Forgot to fit

Why

Difficult
fitment

Repetitive
work

Why

Flash
of lugs

Figure 7

cognizant 20-20 insights

Human Error Causes

Lack of
Knowledge

Forgot

Difficulty
Human
error

Repetition
of work

Figure 8

fective actions that are prone to problem reoccurrence (e.g., developing procedures, correcting
procedures, training, visual aids, etc.). In these
cases, the team needs to revisit the 5-Whys
analysis to clearly understand the causes.
Sometimes, actions derived in the 5-Whys
exercise may appear to be feasible at more than
one level of sub cause(s); in this case, actions
should be diligently selected based on the optimal
choice of the sub-cause, using a decision matrix.
Once the true root causes are identified, multiple
implementation actions could be identified (both
corrective and preventive) to address each root
cause. Completely addressing these root causes
will eliminate nonconformance with a very high
confidence of non-reoccurrence.

Moving Forward
RCA is a crucial point for effectively addressing
nonconformities, especially through complaints
and corrective and protection action. Both inputs
to RCA and the RCA process need to be effective
to arrive at actionable areas to be addressed.
An RCA exercise is only as good as its inputs
and follow-up actions. Even if an RCA is done
effectively, the root causes must be thoroughly
addressed to enable a holistic and non-repeatable
closure of the original nonconformity through
both corrective and preventive measures. Additionally, the effectiveness of the actions must be
verified with documentation.

re-occurrences of the nonconformities. This

helps save considerable effort, cost and time for
addressing recalls and adverse events (if any),
while retaining the active status of the product
in the market for a longer timespan. This also
means increased safety and trust for the product,
with the potential to increase market share.
Typically, a medical device company that
observes or receives a warning about ineffective
RCA needs to first assess its current state (as-is),
followed by a plan for developing a to-be state by
identifying gaps in the process, tools and methodologies utilized. We recommend performing
these actions using a Six-Sigma approach. The
level of modifications required to existing RCA
process will depend on the gaps identified and
could vary from organization to organization. It is
also crucial to train relevant stakeholders on the
modified RCA process.
We also recommend verifying the effectiveness of
the closure of root cause through both corrective
and preventive measures. The methods, tools and
techniques will vary from case to case, with the
need for any one effectiveness verification action
to be authenticated through one or different
means. Effectiveness verification is the last gate
for nonconformity closure and is typically audited
by an experienced independent reviewer.
Cognizant has the required expertise, framework
of RCA process tools and techniques to perform
efficient and effective RCA.

By improving the efficacy of the RCA process,

medical device companies can significantly limit
cognizant 20-20 insights

References

Ten Most Common Reasons for FDA 483 Observations and Warning Letter Citations, Master Control,
Inc., http://images.vertmarkets.com/crlive/files/downloads/e1a9fcbc-2eb4-4835-a885-1e333314dca0/
white_paper_top_10_483.pdf.

Geoff Vorley, Mini Guide to Root Cause Analysis, Quality Management & Training Ltd., 2008, http://
www.root-cause-analysis.co.uk/images/Green%20RCA%20mini%20guide%20v5%20small.pdf.

Guidance

for Performing Root Cause Analysis with Performance Improvement Projects, QAPI,
https://www.cms.gov/medicare/provider-enrollment-and-certification/qapi/downloads/guidanceforrca.pdf.

Mark Paradies, 7 Secrets of Root Cause Analysis, TapRoot, Jan. 7, 2011, http://www.taproot.com/
archives/24425

Bob

Mehta, CAPA and Complaints: Root Cause Investigation, The Quality Management Forum,
Vol. 40, No. 4, Winter 2015, http://www.mddionline.com/article/capa-and-complaints-ascertainingroot-cause.

Jamie Hartford, CAPA and Complaints: Ascertaining Root Cause, MDDI, Dec. 11, 2013, http://www.
mddionline.com/article/capa-and-complaints-ascertaining-root-cause.

Dalgobind Mahto and Anjani Kumar, Application of Root Cause Analysis in Improvement of Product

Quality and Productivity, Journal of Industrial Engineering and Management, Vol. 1, No. 2, 2008,
http://www.jiem.org/index.php/jiem/article/view/3.

Quality Management for Process Improvement, Mahindra Institute of Quality.

Albert W. Wu, Angela K. M. Lipshutz, Peter J. Pronovost, Effectiveness and Efficiency of Root Cause
Analysis in Medicine, The Journal of the American Medical Association, 2008, https://www.researchgate.net/publication/5582469_Effectiveness_and_efficiency_of_root_cause_analysis_in_medicine.

Footnotes
1

A Pareto chart, also called a Pareto distribution diagram, is a verticalbar graphin which values are
plotted in decreasing order of relative frequency from left to right. Pareto charts are extremely useful
for analyzing which problems need attention first because the taller bars on the chart, which represent
frequency, clearly illustrate which variables have the greatest cumulative effect on a given system. The
Pareto chart provides a graphic depiction of the Pareto Principle, a theory maintaining that 80% of
the output in a given situation or system is produced by 20% of the input. Source: Whatis.com, http://
whatis.techtarget.com/definition/Pareto-chart-Pareto-distribution-diagram.

A histogram is a graphical representation of the distribution of numerical data. Source: Wikipedia,

https://en.wikipedia.org/wiki/Histogram.

The 3Gs are a fundamental element of continuous improvement. The concept is that by observing the
actual process at the actual place, the team can base their decision on actual not second-hand facts.
Source: Gembutsu Consulting, http://www.gembutsu.com/gemba_gembutsu_defined.html.

A SIPOC or suppliers, inputs, processes, outputs, customers diagram documents a business process
from beginning to end, serving as a high-level process map. Source: TechTarget, http://searchcio.techtarget.com/definition/SIPOC-diagram-suppliers-inputs-process-outputs-customers.

The Johari Window is a communication model used to improve understanding between individuals.
The word Johari is taken from the names of Joseph Luft and Harry Ingham, who developed the
model in 1955. There are two key ideas behind the tool: That you can build trust with others by disclosing information about yourself, and with the help of feedback from others, you can learn about
yourself and come to terms with personal issues. Source: MindTools, https://www.mindtools.com/CommSkll/JohariWindow.htm.

cognizant 20-20 insights

Preliminary hazard analysis identifies system hazards, translates them into high-level system safety
design constraints, assesses hazards and establishes a hazard log. Source: Safeware Engineering,
http://www.safeware-eng.com/White_Papers/Preliminary%20Hazard%20Analysis.htm.

Fault tree analysis is a top-down, deductive failure analysis that uses Boolean logic to combine a series
of lower level events. Source: Wikipedia, https://en.wikipedia.org/wiki/Fault_tree_analysis.

A HAZOP study is a structured and systematic examination of a planned or existing process or operation, with the goal of identifying and evaluating problems that may represent risks or prevent efficient
operation. Source: Wikipedia, https://en.wikipedia.org/wiki/Hazard_and_operability_study.

Hazard Analysis Critical Control Point (HACCP) is a management system in which food safety is
addressed through the analysis and control of biological, chemical and physical hazards from raw
material production, procurement and handling, to manufacturing, distribution and consumption of
the finished product.Source: FDA, http://www.fda.gov/Food/GuidanceRegulation/HACCP/.

10

A 5-Whys analysis is a technique used in the analyze phase of the Six Sigma DMAIC (define, measure, analyze, improve, control) methodology. By repeatedly asking the question Why (five is a
good rule of thumb), you can peel away the layers of symptoms which can lead to the root cause of
a problem. Source: iSixSigma, http://www.isixsigma.com/tools-templates/cause-effect/determineroot-cause-5-whys/.

11

Dorian Shainin was an American quality consultant and professor who developed a series of problemsolving techniques that have become the core of the Shainin System for quality and reliability improvement. Source: Wikipedia, https://en.wikipedia.org/wiki/Dorian_Shainin.

12

Design of experiments (DOE) is a systematic method for finding cause-and-effect relationships. Source:
iSixSigma, http://www.isixsigma.com/tools-templates/design-of-experiments-doe/design-experiments-%E2%90%93-primer/.

13

Poka-yoke is a Japanese term that means mistake proofing. A poka-yoke device is one that prevents
incorrect parts from being made or assembled, or easily identifies a flaw or error. Source: iSixSigma,
http://www.isixsigma.com/dictionary/poka-yoke/. Kaizen is the practice of continuous improvement.
Source: Kaizen Institute, https://www.kaizen.com/about-us/definition-of-kaizen.html.

cognizant 20-20 insights

About the Authors

Manoj Kadu is Senior Associate of Projects in Cognizants Product Engineering & Lifecycle Management
Practice, with the Engineering and Manufacturing Solutions business unit. He has worked for more than
nine years in the manufacturing industry, in manufacturing, quality and project management roles,
spanning the automotive, agriculture/construction, vehicle and industrial machinery sectors. A certified
Six Sigma Black Belt, Manoj is a mechanical engineering graduate from the University of Pune and earned
his masters degree in business administration (operations management) from IGNOU University. He can
be reached at Manoj.Kadu@cognizant.com.
Madan Unde is Senior Manager of Projects in Cognizants Product Engineering Practice, with the Engineering and Manufacturing Solutions Business Unit. He has over 13.5 years of experience in the engineering industry, working in both engineering OEMs and services organizations providing solutions to
global OEMs. He has worked in multiple industries, including life sciences (medical devices), high-tech,
industrial automation and machine tools, providing solutions across various technical areas, such as
product design and development, innovation, continuous improvement, complaints investigation and
resolution, CAPA management and product sustenance engineering. Madan has actively participated in
and handled concept-to-commercialization of OEM products and has significant experience in technically
managing complex engineering projects. A certified Six Sigma Black Belt Professional and Value Engineering Associate Value Specialist, Madan is a mechanical engineering graduate and industrial engineering
post-graduate, both from the University of Pune. He can be reached at Madan.Unde@cognizant.com.

About Cognizant
Cognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business
process outsourcing services, dedicated to helping the worlds leading companies build stronger businesses. Headquartered in Teaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction,
technology innovation, deep industry and business process expertise, and a global, collaborative workforce that embodies the future of work. With over 100 development and delivery centers worldwide and
approximately 221,700 employees as of December 31, 2015, Cognizant is a member of the NASDAQ-100,
the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performing and
fastest growing companies in the world. Visit us online at www.cognizant.com or follow us on Twitter: Cognizant.

World Headquarters

European Headquarters

India Operations Headquarters

500 Frank W. Burr Blvd.

Teaneck, NJ 07666 USA
Phone: +1 201 801 0233
Fax: +1 201 801 0243
Toll Free: +1 888 937 3277
Email: inquiry@cognizant.com

1 Kingdom Street
Paddington Central
London W2 6BD
Phone: +44 (0) 20 7297 7600
Fax: +44 (0) 20 7121 0102
Email: infouk@cognizant.com

#5/535, Old Mahabalipuram Road

Okkiyam Pettai, Thoraipakkam
Chennai, 600 096 India
Phone: +91 (0) 44 4209 6000
Fax: +91 (0) 44 4209 6060
Email: inquiryindia@cognizant.com

Copyright 2016, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any
means, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein is
subject to change without notice. All other trademarks mentioned herein are the property of their respective owners.

Codex 1806