|
Sample Pages | RCGLOBAL |
| Sample Pages of
EVIDENCE PRODUCT CHECKLIST For the standard IEC 60601-1-4 Edition 1.1 2000-04 IEC 60601-1-4: Medical Electrical Equipment Part 1: General Requirements for Safety. Part 4. Programmable Electrical Medical Systems |
| Introduction
The process of defining what is necessary for compliance with a software engineering process standard such as IEC 60601-1-4 “Medical Electrical Equipment Part 1: General Requirements for Safety. Part 4. Programmable Electrical Medical Systems” is sometimes confusing and laborious because the directions contained in the standard may be unclear or ambiguous. To aid in determining what is actually “required” by the standard in the way of physical evidence of compliance, the experts at SEPT have produced this checklist. This checklist is constructed around a classification scheme of physical evidence comprised of procedures, plans, records, documents, audits, and reviews. SEPT has carefully reviewed IEC 60601-1-4 and defined the physical evidence required based upon this classification scheme. SEPT has conducted a second review of the complete list to ensure that the standard’s producers did not leave out a physical piece of evidence that a “reasonable person” would expect to find. It could certainly be argued that if the document did not call it out then it is not required; however if the standard were used by an enterprise to improve its software process, then it would make sense to recognize missing documents. Therefore, there are documents specified in this checklist that are implied by the standard, though not specifically called out in the standard, and they are designated by an asterisk (*) throughout this checklist. If a document is called out more than one time, only the first reference is stipulated. There are occasional situations in which a procedure or document is
not necessarily separate and could be contained within another document.
For example, the Software Detail Specification Document could be a subset
of Software Design Specification. SEPT has called out these individual
items separately to ensure that the organization does not overlook any
facet of physical evidence. If the organization does not require
a separate document, and an item can be a subset of another document or
record, then this fact should be denoted in the detail section of the checklist
for that item. This should be done in the form of a statement reflecting
that the information for this document may be found in section XX of Document
XYZ. If the organizational requirements do not call for this physical
evidence for a particular project, this should also be denoted with a statement
reflecting that this physical evidence is not required and why. The
reasons for the evidence not being required should be clearly presented
in this statement. Further details on this step are provided in the
in the Detail Steps section of the introduction. The size of these
documents could vary from paragraphs to volumes depending upon the size
and complexity of the software project or business requirements.
All reasonable questions concerning this checklist or its use will be addressed free of charge for 60 days from time of purchase, up to a maximum of 4 hours consultation time. Author’s Qualifications
|
|
|
|
|
|
|
|
| 1.203 Relationship to Other Standards | . | . | . | . | . |
| 1.203.3 |
|
|
|
|
|
| 6.0 Identification, Marking and Documents | . | . | . | . | . |
| 6.8.201 |
|
. |
|
|
|
| 6.8.202 | . | . |
|
. | . |
| 52.201 Documentation | . | . | . | . | . |
| 52.201.1 |
|
|
|
. |
|
| 52.201.2 | . | . | . | . | . |
| © 2004. Software Engineering Process Technology (SEPT) All rights reserved. |
| RCGLOBAL
Home / Contact us: rcgroup@rcglobal.com |