- Email: [email protected]
Hardware and Software Development for Safety-Related Medical Devices
Copyright © IFAC Safety and Reliability in Emerging Control Technologies. Daytona Beach. Florida. USA. 1995
HARDWARE AND SOFTWARE DEVELOPMENT FOR SAFETY-RELATED MEDICAL DEVICES Jerzy Orkiszewski Coherent Inc., Medical Group, Palo Alto, California, USA
Abstract: Article addresses various aspects of system level design of a safety-related medical device. The main factors influencing the design and its division between software and hardware are: main hazards, intended use of the device and severity of a potential failure. Other factors include probability of change, testability and volume of production. End user's profile, time-to-market and life cycle of the device are also reviewed. The impact of both domestic and international regulations is discussed. A high level design process of an example medical laser is presented. Keywords: Medical systems, Software safety, Real-time systems, Redundancy, Hardware
1. INTRODUCTION
2.1 Regulations
A designer working on a medical device must choose solutions that are not only solid from an engineering and marketing standpoint, but also safe to patients and medical personnel. These requirements strongly influence the architecture of device control system. After reviewing all the factors the system level designer must decide which subsystems will be implemented in software and which in hardware. Al so, if redundancy is needed, decision has to be made whether it should be implemented as parallel hardware systems or by running parallel programs on a multi-processor system.
General requirements for the design and operation of the electrical medical devices come from IEC 601 (lEC 1998) family of standards. This set of standards addresses General Requirements for Safety (IEC 601-1), Safety Requirements for Medical Electrical Systems (IEC 601-1-1) as well as Requirements for Particular Device (IEC 1992). Generally compliance with IEC 601 is required in most of the countries. Recently a new standard was proposed. Its goal is to address issues related to software driven devices. Known as IEC 601-1-4, Safety Requirements for Programmable Electronic Medical Systems, this proposed standard may have tremendous impact on the way medical software is written.
To make right decisions several factors must be considered. Among the most important are: potential hazards that the instruments may impose on patients or medical personnel, intended use of the device and probability of change of its specifications. Also important are volume of production, required time to market and available resources.
Additionally almost every country has some local regulations. Currently EC countries made important step towards unification of national regulations by creating a common certificate of compliance called CE Mark. CE Mark may be:1ssued by a licensed agency of any of EC countries. Also, the manufacturer of the device may become licensed to issue CE Mark for his own instrument. In order to become a self-certifying manufacturer, the factory must be licensed by one of the national agencies of CE countries such as British BSI or German TUV. Requirements are similar to IS09000 and IS09002.
2. GENERAL SAFETY REQUIREMENTS In order to be considered for sale all the medical systems must conform to certain international and national regulations.
49
4. IMPLEMENTATION OF SAFETY FEATURES
Additionally, for every device a file must be maintained that contains documentation and results of all the test. Often specific tests are done by one of the national licensing agencies.
Hazard analysis points to specific hazards and offers mitigations. The physical implementation of the safety features is chosen based on mitigations and other criteria, some of which is listed below.
Licensing process in USA is controlled by Food and Drug Administration. FDA recognizes different levels and scopes of approvals depending on intended application and current state of art in a given field. A limited number of devices may be given pennission to be used in a limited number of pre-approved clinical sites in order to conduct specific study according to an accepted scientific protocol. A license like this, called IDE (Investigational Device Exemption) may lead to multi-stage clinical study and finally to a full marketing approval.
4.1 Controller architecture A core of a controller is typically build around one microprocessor and its 10 subsystem. Depending on the application some 10 systems may be redundant. In other designs redundancy is implemented by using second cpu. Its purpose is to constantly watch all the safety critical activities of the main CPU and react if errors occur in its operations. Some designs incorporate both dual CPU architecture and redundant input! output subsystems.
3. DEVICE SPECIFIC SAFETY REQUIREMENTS
Software intensive designs are more and more popular. There are many advantages in using software driven systems. Flexibility, sophisticated user's interfaces and lower production costs are often quoted. Once a powerful microprocessor system is used in the design it is also often very convinient to implement most of the safety features in software. Dual CPU designs are examples of software intensive systems with many hazards also mitigated in software.
lEC standards address only most general rules of the safety. Most of the safety related challenges come from the analysis of every specific device. Even similar devices, belonging to the same group according to IEC 601-2, may have very different set of hazards. In order to recognize all of them, the Hazard Analysis in performed. 3.1 Hazard analysis
4.2 Design criteria
Hazard Analysis is always a starting point for any medical control system design. The goal is to identify all possibile hazards in the device. Design group must answer questions such as 'What can go wrong?' ' Can our device be misused?'. During analysis several factors should be considered, such as failure rates and modes, test intervals and diagnostic coverage. Once all the hazards are known, the next step is to find best ways of mitigating them.
In order to make the best decision about the architecture of the controller several criteria should be considered. They should be used to help allocate tasks to hardware, software or both. Some of such criteria are listed below. Intended use of the device. Application of the device (diagnostics, therapeutic, life support) determines the level of the redundancy in the system. In many diagnostics and therapeutic systems it is sufficient to recognize the device failure and stop its operation in a safe state. In other systems the device should be capable of finishing the procedure with some of the parameters limited and then stopping its operation safely. Life supporting device should have enough redundancy built in to continue its critical mission even with a component or subsystem failure. As an example, let us consider two different medical lasers.
Most medical regulatory agencies recognize three ways of mitigating hazards: in hardware, in software or by labeling. Typically labeling is the last line of defense. As an example, a label is placed next to an output aperture of the medical laser to warn the operator against looking directly into the beam. Most hazards related to the specific operation of the device will be prevented by either dedicated hardware of software. Additional requirement imposed on the control system is that no single fault condition will be present. What it really means is that a malfunction of one physical component used to control the system should not compromise its safety. Such condition applies equally to a resistor, logical gate as well as 32 bit CPU.
The first one would be a laser emitting in far infrared portion of the spectrum. Due to the interaction between laser energy in this wavelength and the skin, it is mainly used in dermatology and cosmetic surgery. As with all medical lasers its main hazards are energy over (or under) acceptable limits around requested energy and repetition rate outside limits. Since interrupting the procedure typically 50
accustomed to dealing with advanced technology. This situation is often very visible during trade shows and conventions, where both doctors and lower medical personnel are overwhelmed by new instruments. What it means for the system designer is that the user's interface has to be considered very carefully. A good user's interface must be simple and intuitive. It is often pointed out that the best medical device interface would have only one button. Practically the interface must emphasize the most important features of the device and offer some help in leading the user along the procedure.
does not have any negative effect on the medical process, any error registered by the system should immediately stop the exposure. Depending on the type of error, its cause may be corrected and the treatment can continue later at any time. Different situation exists with excimer lasers used in ophthalmology. Such lasers, emitting in UV, are used to ablate cornea in order to reshape it and create change in corneal refractive power thus correcting myopia, hyperopia or astigmatism. Typical treatment consists of about one hundred pulses of specially formed laser beam. Each pulse ablates selected area of the cornea.
Safety is a very important factor in designing the interface. Many unsafe situations are originated by the operator misinterpreting of the system settings. A good interface should foresee such situations and force the user to acknowledge any drastic change of the system parameters or mode of operation.
There are two popular types of the treatment. In both of them interrupting the treatment has major medical consequences. This problem manifests itself especially in so called flap-and-zap procedure where the change of optical power is first calculated and then the top portion of the cornea is sliced to produce access to its internal structure. Laser treatment is performed and the top portion of the cornea is put back in place. Due to factors such as drying, time window for treatment is few minutes after the initial cut. If the treatment is interrupted and can not be resumed within two minutes the top of the cornea has to be put back. Only after several months the patient has to be evaluated again, the new treatment has to be calculated and a new procedure can be performed.
All the above requirements point again to software as a preferred way of implementing all the interface functionality. Time to market Time needed to develop the controller is also a factor that favors software intensive solutions. Once the basic architecture of the controller is established, its design process may be done in parallel with software development. Resources. Available resources are also an important factor. Falling into that category are both people and tools. Software intensive products may require using newer, more powerful microprocessors. Using new CPU has its consequences both in terms of time and money. New tools must be purchased. The price of the assembler, compiler and emulator can easily reach $50K. Programmers have to learn new assembler and the details of the compiler. Responsible for hardware have to learn new architecture. It is often faster and cheaper to stay with older, less powerful CPU and build all the redundancy and safety features using well-known hardware based logic.
Due to such restrictions it is required that the system try to finish treatment even if some errors are encountered. It applies specifically to errors in pulse energy. It is desirable that the system software would be capable to respond in real time to such conditions as energy lower then expected and calculate new treatment parameters. Probability of change. Change of specifications after the device has been already built is encountered mostly when designing new, experimental device or ex'tending range of applications for an existing instrument. Often clinical investigations lead to redefining some of the system parameters or modes of operation. Typically, software based devices are much easier to change.
4.3 Software safety features In order to make software operation as safe as possibile a number of design rules are used. Here are some of them.
Volume of productioIl For devices that are mass produced, minimization of the bill of material is required. On the other hand the volume of production in medical industry seldom justifies using ASICs or other custom chips. Using software to implement safety features limits number of the components on the controller PCB and lowers the unit cost of the device. End user profile. Typical end user of the medical device is not a technical professional nor a person 51
•
All the program memory;·'must be verified during run time by calculating its CRC and verifying it against stored value.
•
All the data memory must be extensively tested during startup.
•
Any battery backup memory must be tested usingCRC.
•
•
Every digital output should be verified by reading the port back.
•
In a dual CPU architecture the communication between both CPUs should be tested. Such communication is often implemented by dual ported RAM or serial ports.
•
port over and over again. Alternatively, the output AID port may be cleared after each read.
Extensive test of the CPU must be done. It is desired that every CPU instruction will be executed and the results tested. Same set of tests applies to various addressing modes of the CPU.
•
5. TESTINGANDOOCUMENTATION Testing of the system safety features is one of the most important parts of device development. Together with the documentation it can take considerable amount of time.
In a dual CPU architecture the safety CPU ability to stop the system in case of errors should be tested. It is accomplished by causing the error condition in the system and watching safety CPU response.
•
All the error exception handlers should redirect to a routine that would attempt to safely shut down the system. No error exception should be left unguarded. A good example of such exception in 680xO architecture is Bus Error exception.
•
All analog to digital converters should be tested on startup by looping back the outputs of the DJ A converter.
•
Lack of cross coupling between DJA converters outputs should be checked.
It is interesting to look at the regulatory approach to testing and documentation. Generally, foreign approval bodies favor system testing done by an appointed person over the written documentation. Food and Drug Administration has almost opposite approach. FDA inspection requires a set of documents, almost all related to software. Documents basically need to follow IEEE standards and include Software Requirements Specification (SRS), Software Design Document (SDD), Software Verification and Validation Document (V&V) as well as the testing results. Specifically, SDD includes a detailed description of every function used in every module. It should also include process flow description in a form of a flow chart or pseudo code.
Another very important point for FDA is traceability matrix. Every test done on a function or a module must be related back to V&V and farther to SDD and SRS. Hazard Analysis relates to each and every of those documents.
4.4 Hardware safety features Some basic rules of hardware design also apply. Mainly: •
•
Hardware design is on the other hand almost disregarded by FDA.
Gates on safety critical lines should be located in different packages.
Recent "FDA Guidance for Photorefractive Keratectomy Laser Systems" (FDA 1995) requires only that the manufacturer provide hardware "macro schematic." Also, " ... detailed schematics should be accompanied by a narrative description... " This document also states that the commercial computer can be used and including it in the electrical description is "not necessary". On the other hand, software descriptions include 12 items: Software Version Number, System Requirements ( which fall into software category ), Software Requirements, Software Hazard Analysis, System Specifications, Software Specifications, Software Developments Methods, System Software Description, Software Environment Description, Software Algorithms and Flowcharts, Description of the Corneal Surface During PRK as well as Changes and Maintenance Standard Operating Procedure.
Operational amplifies located on safety critical signal path should be located in different packages.
4.5 System safety features Safety features which implementation is divided between hardware and software include the following. •
All the power supply voltages on the board should be monitored and compared with positive and negative limits.
•
All the AID conversions should be monitored. Specifically, start of conversion should be monitored as well as the end of conversion. It is done to prevent reading the same value from the
All the timebase interrupts must be monitored. It is often accomplished by implementing a hardware watchdog re-triggered by software from theISR
52
means that medical device designers will try to use them in their interments. It is almost impossible to validate such software products. As such, the basic rule of their use should be not to use them in real time, safety critical part of the design. Still, they may be used specifically to implement user interface only and communicate with the fully embedded system running real time process.
6. EXAMPLE DESIGN As an example let us consider a medical laser used in dermatology. Its main parameters include energy per pulse and repetition rate. Both those parameters describe average power. Hazard analysis shows that main hazards are over exposure (by means of energy or rate higher than required), under exposure (energy or rate lower) and inadvertent exposure. Hence energy and rare monitoring appear to be the most important.
7.3 New medical technologies Medical technology goes often much faster than the appropriate regulations. Even though hazards are mitigated due to the results of Hazard Analysis, the lack of regulations may cause misinterpretations on behalf of either the designer or the licensing body. Laser scanner may serve as an example of not yet regulated new technology. Laser scanner is a device that produces pre-defined patterns of the light. It is used in medicine in order to increase precision on the laser beam positioning. Known for a long time in entertainment industry, scanner only recently found its way to medical technology. One of the most important features associated with such scanner is the pattern itself. What it means is that the system has to guarantee that a pattern is produced and laser pulses will not be delivered into the same spot. At the other hand there is no regulations addressing this issue. It can be argued that since laser energy and rate stay within limits, laser delivers beam as expected.
In order to read energy two monitor circuits are implemented. Because of a potential danger caused by the laser (output up to 100 W) two CPUs are used. The first CPU, called main, monitors all the parameters and provides command for the energy servo system. The second CPU, called safety, monitors main parameters and has authority to stop the exposure by blocking the servo system, output drivers and laser power supply. Rate monitoring is implemented by two independent counters, one read by main CPU and the other one by safety CPU. Both CPUs read and compare two energy readings coming from both energy detectors. Decision to continue the treatment is made by both CPUs on pulse by pulse basis. Taking into the consideration the maximum output power of the laser and the fact that analog signals corresponding to pulse energy are present in the system, additional hardware comparators is used. Its task is to compare each pulse energy with limits driven from a servo command signal and stop the exposure if limits are crossed.
8. CONCLUSIONS Design process of a control system of a medical device is complex. Many factors influence the choices. Principal consideration is the safety of the patient and the medical staff. Software is used more and more often as a means of implementing both control and safety functions of the system. This approach leads to dual CPU architectures and increasing demands imposed on system testing.
7. NEW TECHNOLOGIES There are a lot of new challenges facing the designer of safety system of medical device. Some are listed below. The list is just an example of some new hardware, software and medical challenges.
REFERENCES International Electrotechnical Commission, International Standard IEC 601-1 , Geneve (1988) International Electrotechnical Commission, International Standard IEC 601-2-22 , Geneve (1992) Proposed Draft Guidance jor Photorefractive Keratectomy Laser Systems, IDE Studies and PMA Submissions, Department of Health and Human Services, Food and Drug Administration, Rockville, Maryland, (June 1995)
7.1 Programmable logic Use of programmable logic such as FPGAs is an example of a new hardware feature. There are no specific directives as to their use. It seems reasonable to build test patterns into the device and treat it as any other logic on board. It applies also to RAM based devices such as Xilinx. 7.2 Graphical User Interfaces Increasing popularity of advanced user interfaces such as offered by MS Windows or X-Window 53
HARDWARE AND SOFTWARE DEVELOPMENT FOR SAFETY-RELATED MEDICAL DEVICES Jerzy Orkiszewski Coherent Inc., Medical Group, Palo Alto, California, USA
Abstract: Article addresses various aspects of system level design of a safety-related medical device. The main factors influencing the design and its division between software and hardware are: main hazards, intended use of the device and severity of a potential failure. Other factors include probability of change, testability and volume of production. End user's profile, time-to-market and life cycle of the device are also reviewed. The impact of both domestic and international regulations is discussed. A high level design process of an example medical laser is presented. Keywords: Medical systems, Software safety, Real-time systems, Redundancy, Hardware
1. INTRODUCTION
2.1 Regulations
A designer working on a medical device must choose solutions that are not only solid from an engineering and marketing standpoint, but also safe to patients and medical personnel. These requirements strongly influence the architecture of device control system. After reviewing all the factors the system level designer must decide which subsystems will be implemented in software and which in hardware. Al so, if redundancy is needed, decision has to be made whether it should be implemented as parallel hardware systems or by running parallel programs on a multi-processor system.
General requirements for the design and operation of the electrical medical devices come from IEC 601 (lEC 1998) family of standards. This set of standards addresses General Requirements for Safety (IEC 601-1), Safety Requirements for Medical Electrical Systems (IEC 601-1-1) as well as Requirements for Particular Device (IEC 1992). Generally compliance with IEC 601 is required in most of the countries. Recently a new standard was proposed. Its goal is to address issues related to software driven devices. Known as IEC 601-1-4, Safety Requirements for Programmable Electronic Medical Systems, this proposed standard may have tremendous impact on the way medical software is written.
To make right decisions several factors must be considered. Among the most important are: potential hazards that the instruments may impose on patients or medical personnel, intended use of the device and probability of change of its specifications. Also important are volume of production, required time to market and available resources.
Additionally almost every country has some local regulations. Currently EC countries made important step towards unification of national regulations by creating a common certificate of compliance called CE Mark. CE Mark may be:1ssued by a licensed agency of any of EC countries. Also, the manufacturer of the device may become licensed to issue CE Mark for his own instrument. In order to become a self-certifying manufacturer, the factory must be licensed by one of the national agencies of CE countries such as British BSI or German TUV. Requirements are similar to IS09000 and IS09002.
2. GENERAL SAFETY REQUIREMENTS In order to be considered for sale all the medical systems must conform to certain international and national regulations.
49
4. IMPLEMENTATION OF SAFETY FEATURES
Additionally, for every device a file must be maintained that contains documentation and results of all the test. Often specific tests are done by one of the national licensing agencies.
Hazard analysis points to specific hazards and offers mitigations. The physical implementation of the safety features is chosen based on mitigations and other criteria, some of which is listed below.
Licensing process in USA is controlled by Food and Drug Administration. FDA recognizes different levels and scopes of approvals depending on intended application and current state of art in a given field. A limited number of devices may be given pennission to be used in a limited number of pre-approved clinical sites in order to conduct specific study according to an accepted scientific protocol. A license like this, called IDE (Investigational Device Exemption) may lead to multi-stage clinical study and finally to a full marketing approval.
4.1 Controller architecture A core of a controller is typically build around one microprocessor and its 10 subsystem. Depending on the application some 10 systems may be redundant. In other designs redundancy is implemented by using second cpu. Its purpose is to constantly watch all the safety critical activities of the main CPU and react if errors occur in its operations. Some designs incorporate both dual CPU architecture and redundant input! output subsystems.
3. DEVICE SPECIFIC SAFETY REQUIREMENTS
Software intensive designs are more and more popular. There are many advantages in using software driven systems. Flexibility, sophisticated user's interfaces and lower production costs are often quoted. Once a powerful microprocessor system is used in the design it is also often very convinient to implement most of the safety features in software. Dual CPU designs are examples of software intensive systems with many hazards also mitigated in software.
lEC standards address only most general rules of the safety. Most of the safety related challenges come from the analysis of every specific device. Even similar devices, belonging to the same group according to IEC 601-2, may have very different set of hazards. In order to recognize all of them, the Hazard Analysis in performed. 3.1 Hazard analysis
4.2 Design criteria
Hazard Analysis is always a starting point for any medical control system design. The goal is to identify all possibile hazards in the device. Design group must answer questions such as 'What can go wrong?' ' Can our device be misused?'. During analysis several factors should be considered, such as failure rates and modes, test intervals and diagnostic coverage. Once all the hazards are known, the next step is to find best ways of mitigating them.
In order to make the best decision about the architecture of the controller several criteria should be considered. They should be used to help allocate tasks to hardware, software or both. Some of such criteria are listed below. Intended use of the device. Application of the device (diagnostics, therapeutic, life support) determines the level of the redundancy in the system. In many diagnostics and therapeutic systems it is sufficient to recognize the device failure and stop its operation in a safe state. In other systems the device should be capable of finishing the procedure with some of the parameters limited and then stopping its operation safely. Life supporting device should have enough redundancy built in to continue its critical mission even with a component or subsystem failure. As an example, let us consider two different medical lasers.
Most medical regulatory agencies recognize three ways of mitigating hazards: in hardware, in software or by labeling. Typically labeling is the last line of defense. As an example, a label is placed next to an output aperture of the medical laser to warn the operator against looking directly into the beam. Most hazards related to the specific operation of the device will be prevented by either dedicated hardware of software. Additional requirement imposed on the control system is that no single fault condition will be present. What it really means is that a malfunction of one physical component used to control the system should not compromise its safety. Such condition applies equally to a resistor, logical gate as well as 32 bit CPU.
The first one would be a laser emitting in far infrared portion of the spectrum. Due to the interaction between laser energy in this wavelength and the skin, it is mainly used in dermatology and cosmetic surgery. As with all medical lasers its main hazards are energy over (or under) acceptable limits around requested energy and repetition rate outside limits. Since interrupting the procedure typically 50
accustomed to dealing with advanced technology. This situation is often very visible during trade shows and conventions, where both doctors and lower medical personnel are overwhelmed by new instruments. What it means for the system designer is that the user's interface has to be considered very carefully. A good user's interface must be simple and intuitive. It is often pointed out that the best medical device interface would have only one button. Practically the interface must emphasize the most important features of the device and offer some help in leading the user along the procedure.
does not have any negative effect on the medical process, any error registered by the system should immediately stop the exposure. Depending on the type of error, its cause may be corrected and the treatment can continue later at any time. Different situation exists with excimer lasers used in ophthalmology. Such lasers, emitting in UV, are used to ablate cornea in order to reshape it and create change in corneal refractive power thus correcting myopia, hyperopia or astigmatism. Typical treatment consists of about one hundred pulses of specially formed laser beam. Each pulse ablates selected area of the cornea.
Safety is a very important factor in designing the interface. Many unsafe situations are originated by the operator misinterpreting of the system settings. A good interface should foresee such situations and force the user to acknowledge any drastic change of the system parameters or mode of operation.
There are two popular types of the treatment. In both of them interrupting the treatment has major medical consequences. This problem manifests itself especially in so called flap-and-zap procedure where the change of optical power is first calculated and then the top portion of the cornea is sliced to produce access to its internal structure. Laser treatment is performed and the top portion of the cornea is put back in place. Due to factors such as drying, time window for treatment is few minutes after the initial cut. If the treatment is interrupted and can not be resumed within two minutes the top of the cornea has to be put back. Only after several months the patient has to be evaluated again, the new treatment has to be calculated and a new procedure can be performed.
All the above requirements point again to software as a preferred way of implementing all the interface functionality. Time to market Time needed to develop the controller is also a factor that favors software intensive solutions. Once the basic architecture of the controller is established, its design process may be done in parallel with software development. Resources. Available resources are also an important factor. Falling into that category are both people and tools. Software intensive products may require using newer, more powerful microprocessors. Using new CPU has its consequences both in terms of time and money. New tools must be purchased. The price of the assembler, compiler and emulator can easily reach $50K. Programmers have to learn new assembler and the details of the compiler. Responsible for hardware have to learn new architecture. It is often faster and cheaper to stay with older, less powerful CPU and build all the redundancy and safety features using well-known hardware based logic.
Due to such restrictions it is required that the system try to finish treatment even if some errors are encountered. It applies specifically to errors in pulse energy. It is desirable that the system software would be capable to respond in real time to such conditions as energy lower then expected and calculate new treatment parameters. Probability of change. Change of specifications after the device has been already built is encountered mostly when designing new, experimental device or ex'tending range of applications for an existing instrument. Often clinical investigations lead to redefining some of the system parameters or modes of operation. Typically, software based devices are much easier to change.
4.3 Software safety features In order to make software operation as safe as possibile a number of design rules are used. Here are some of them.
Volume of productioIl For devices that are mass produced, minimization of the bill of material is required. On the other hand the volume of production in medical industry seldom justifies using ASICs or other custom chips. Using software to implement safety features limits number of the components on the controller PCB and lowers the unit cost of the device. End user profile. Typical end user of the medical device is not a technical professional nor a person 51
•
All the program memory;·'must be verified during run time by calculating its CRC and verifying it against stored value.
•
All the data memory must be extensively tested during startup.
•
Any battery backup memory must be tested usingCRC.
•
•
Every digital output should be verified by reading the port back.
•
In a dual CPU architecture the communication between both CPUs should be tested. Such communication is often implemented by dual ported RAM or serial ports.
•
port over and over again. Alternatively, the output AID port may be cleared after each read.
Extensive test of the CPU must be done. It is desired that every CPU instruction will be executed and the results tested. Same set of tests applies to various addressing modes of the CPU.
•
5. TESTINGANDOOCUMENTATION Testing of the system safety features is one of the most important parts of device development. Together with the documentation it can take considerable amount of time.
In a dual CPU architecture the safety CPU ability to stop the system in case of errors should be tested. It is accomplished by causing the error condition in the system and watching safety CPU response.
•
All the error exception handlers should redirect to a routine that would attempt to safely shut down the system. No error exception should be left unguarded. A good example of such exception in 680xO architecture is Bus Error exception.
•
All analog to digital converters should be tested on startup by looping back the outputs of the DJ A converter.
•
Lack of cross coupling between DJA converters outputs should be checked.
It is interesting to look at the regulatory approach to testing and documentation. Generally, foreign approval bodies favor system testing done by an appointed person over the written documentation. Food and Drug Administration has almost opposite approach. FDA inspection requires a set of documents, almost all related to software. Documents basically need to follow IEEE standards and include Software Requirements Specification (SRS), Software Design Document (SDD), Software Verification and Validation Document (V&V) as well as the testing results. Specifically, SDD includes a detailed description of every function used in every module. It should also include process flow description in a form of a flow chart or pseudo code.
Another very important point for FDA is traceability matrix. Every test done on a function or a module must be related back to V&V and farther to SDD and SRS. Hazard Analysis relates to each and every of those documents.
4.4 Hardware safety features Some basic rules of hardware design also apply. Mainly: •
•
Hardware design is on the other hand almost disregarded by FDA.
Gates on safety critical lines should be located in different packages.
Recent "FDA Guidance for Photorefractive Keratectomy Laser Systems" (FDA 1995) requires only that the manufacturer provide hardware "macro schematic." Also, " ... detailed schematics should be accompanied by a narrative description... " This document also states that the commercial computer can be used and including it in the electrical description is "not necessary". On the other hand, software descriptions include 12 items: Software Version Number, System Requirements ( which fall into software category ), Software Requirements, Software Hazard Analysis, System Specifications, Software Specifications, Software Developments Methods, System Software Description, Software Environment Description, Software Algorithms and Flowcharts, Description of the Corneal Surface During PRK as well as Changes and Maintenance Standard Operating Procedure.
Operational amplifies located on safety critical signal path should be located in different packages.
4.5 System safety features Safety features which implementation is divided between hardware and software include the following. •
All the power supply voltages on the board should be monitored and compared with positive and negative limits.
•
All the AID conversions should be monitored. Specifically, start of conversion should be monitored as well as the end of conversion. It is done to prevent reading the same value from the
All the timebase interrupts must be monitored. It is often accomplished by implementing a hardware watchdog re-triggered by software from theISR
52
means that medical device designers will try to use them in their interments. It is almost impossible to validate such software products. As such, the basic rule of their use should be not to use them in real time, safety critical part of the design. Still, they may be used specifically to implement user interface only and communicate with the fully embedded system running real time process.
6. EXAMPLE DESIGN As an example let us consider a medical laser used in dermatology. Its main parameters include energy per pulse and repetition rate. Both those parameters describe average power. Hazard analysis shows that main hazards are over exposure (by means of energy or rate higher than required), under exposure (energy or rate lower) and inadvertent exposure. Hence energy and rare monitoring appear to be the most important.
7.3 New medical technologies Medical technology goes often much faster than the appropriate regulations. Even though hazards are mitigated due to the results of Hazard Analysis, the lack of regulations may cause misinterpretations on behalf of either the designer or the licensing body. Laser scanner may serve as an example of not yet regulated new technology. Laser scanner is a device that produces pre-defined patterns of the light. It is used in medicine in order to increase precision on the laser beam positioning. Known for a long time in entertainment industry, scanner only recently found its way to medical technology. One of the most important features associated with such scanner is the pattern itself. What it means is that the system has to guarantee that a pattern is produced and laser pulses will not be delivered into the same spot. At the other hand there is no regulations addressing this issue. It can be argued that since laser energy and rate stay within limits, laser delivers beam as expected.
In order to read energy two monitor circuits are implemented. Because of a potential danger caused by the laser (output up to 100 W) two CPUs are used. The first CPU, called main, monitors all the parameters and provides command for the energy servo system. The second CPU, called safety, monitors main parameters and has authority to stop the exposure by blocking the servo system, output drivers and laser power supply. Rate monitoring is implemented by two independent counters, one read by main CPU and the other one by safety CPU. Both CPUs read and compare two energy readings coming from both energy detectors. Decision to continue the treatment is made by both CPUs on pulse by pulse basis. Taking into the consideration the maximum output power of the laser and the fact that analog signals corresponding to pulse energy are present in the system, additional hardware comparators is used. Its task is to compare each pulse energy with limits driven from a servo command signal and stop the exposure if limits are crossed.
8. CONCLUSIONS Design process of a control system of a medical device is complex. Many factors influence the choices. Principal consideration is the safety of the patient and the medical staff. Software is used more and more often as a means of implementing both control and safety functions of the system. This approach leads to dual CPU architectures and increasing demands imposed on system testing.
7. NEW TECHNOLOGIES There are a lot of new challenges facing the designer of safety system of medical device. Some are listed below. The list is just an example of some new hardware, software and medical challenges.
REFERENCES International Electrotechnical Commission, International Standard IEC 601-1 , Geneve (1988) International Electrotechnical Commission, International Standard IEC 601-2-22 , Geneve (1992) Proposed Draft Guidance jor Photorefractive Keratectomy Laser Systems, IDE Studies and PMA Submissions, Department of Health and Human Services, Food and Drug Administration, Rockville, Maryland, (June 1995)
7.1 Programmable logic Use of programmable logic such as FPGAs is an example of a new hardware feature. There are no specific directives as to their use. It seems reasonable to build test patterns into the device and treat it as any other logic on board. It applies also to RAM based devices such as Xilinx. 7.2 Graphical User Interfaces Increasing popularity of advanced user interfaces such as offered by MS Windows or X-Window 53