Guidelines for medical alarm system software...

Altran Italia | Technology Review # 08

Pasquale Sessa

ABSTRACT:

The kidneys are responsible for filtering waste pro-ducts from the blood. The dialysis is a procedu-re to replace the renal (kidney) function through Haemodialysis machine in people who suffer from end stage renal disease. Haemodialysis machine provide the fluids of dialysis for the cleaning of the patient’s blood and removal of excess fluid.One aspect to take care in the development of a dialysis machine is the alarm system. Alarm systems are important for safe and efficient operation of many technical systems. However, it is vital that the design of the alarms and the alarm system matches the conditions and needs of the human operator. During treatment multiple alarm can occur but we must ensure that the alarm must be accu-rate, intuitive, and provide alerts which are re-adily interpreted. Audible alarms serve mul-tiple functions in medical equipment, not the least of which is that they protect manufacturers against liability. This article is offe-red as to facilitate the improvement of alarm de-sign; on the other hand give some tips to develop alarm uniformity. In order to accomplish this, it is necessary to approach the management of alarm troubleshooting in a systematic manner. The title of the article refers to the IEC 60601-1-8, a com-prehensive international standard that specifies ba-sic safety and essential performance requirements and tests for alarm systems in medical equipment. Medical equipment manufacturers usually develop proprietary alarms for their products. Efforts to har-monize alarm systems in medical equipment had been moving slowly over the last decade. As devi-ce makers continue to integrate more functions into each piece of medical equipment, they must also incorporate more types of warning sounds.

Guidelines for medical alarm system software design

1. Introduction:

What defines a visual alarm?It’s a good question. However, this changed in 2003 when international standard IEC 60601-1-8 was issued. Although compliance is voluntary, it is ex-pected that many medical equipment manufacturers will eventually move toward adopting this standard. In not following its guidance, manufacturers risk lia-bility issues, but even more, they risk missing out on sales to larger institutions that may soon begin to require compliance to IEC 60601-1-8. The defi-nitions of “alarm system” and “alarm condition” in IEC 60601-1-8 are not really tight enough to exclude an information message, since it is still to indicate a potential hazard. It appears the scope statement (clause 1.1) that the decision to use an “alarm sy-stem” is up to the manufacturer. Some particular standards specify that an alarm must be provided, also there are some Manufacturing Details Design (MDD) essential requirements that specifically refe-rence alarms. In all other cases the risk management process will decide if an alarm is needed. Just for additional justification, although nowhere stated, the principle of IEC 60601-1-8 alarms is to bring the users attention to the equipment generating the alarm, in an environment where there may be many medical devices or where the user may have their attention on other things. In your case the user is already sitting in front of the device, looking at the screen, and has just made a change in setting that might trigger the message. Thus, there is no need to try and grab the user’s attention to your device, such as by providing a lamp, audible sound etc. So perhaps an improved definition of an “alarm system” in IEC 60601-1-8 would indicate that such systems are specifically intended to get the user’s attention from a distance, through the use of audible and vi-sual signals. The IEC 60601-1-8 is a collateral stan-dard. It applies to all medical electrical devices that provide audible or visual signals to reduce risk. For the standard the alarms are any signal to prevent an harm.The IEC 60601-1-8 allows to modify the design or eliminate some requirements.

The methods presented in this article have been de-veloped as general guidance to develop alarm sy-stem architecture in a medical electrical system.

16


Why create a standard for alarms? Identified problems included difficulty in identifying the source of an alarm, alarms being too loud and distracting, and high rates of false-positive or nega-tive alarm conditions. The safety is improved, throu-gh improved perception (understanding) by clini-cians. If the user understand the urgency and cause, quicker action is taken. It is should be emphasized that lower priority alarms are not unnecessarily di-stracting or disturbing.The designer determines the priority of the condi-tion being monitored by the medical equipment. Any signal that is intended to alert users to a poten-tially harmful condition or situation so that action can be taken to prevent harm is an alarm signal. The equipment designer is responsible for gauging when an alarm should trigger. In such cases, clau-se 201.3.1 requires that at minimum a visual alarm must be generated.A visual alarm is not necessary for alarm systems that are worn, such a paging receiver. Whether audi-ble or other type of signals are required is determi-ned by risk analysis.

What are the situations that make alert the user to?Any situations dangerous for patient health or used to indicate the quality of the treatment.The alarms can be divided into two macro types: physiological and technical alarms. The physiological class type contains all alarm con-ditions when a dialysis parameter value is out of permitted range, exceeds a threshold and is dan-gerous for the health of the patient. The machine control arterial pressure that is the pressure in the arterial blood line between your needle and the blo-od pump. It is always negative because the pump is pulling the blood from the needle. If the machine is trying to pull blood from you faster than the needle can give it, an alarm will activate (high arterial pres-sure). This alarm will stop the blood pump and close the venous line clamp. In this example we show the definition of the physiological alarm but is evident the haemodialysis machine state after the alarm ac-tivation. Alarms that cause the blood pump to stop should be managed as quickly as possible, because if the blood is stagnant in the tubing for too long, it will clot. Excessive clotting in the blood tubing may result in needing to change the entire blood tubing set, which is a time-consuming procedure. The monitor parameters are different such as high heart rate, low exhaled tidal volume (Ventilator) etc. and the machine alarm state depends from there. To classify the alarms clearly is necessary define some attributes that following I want to deal. Instead the technical alarms are failure of essential performan-ce also during single fault condition or mechanical failure resulting in a hazard or processing error (in safety related). Anyway in both classes we need to define other attribute to define clearly the alarms. When we develop the software part of the dialysis

system we must remember that is needed to inte-ract clearly with the hardware and mechanical parts of the system and comply with the regulation the machine state at the alarm activation is a safe sta-te in the shortest possible time. However, in some applications such as medical equipment, a person’s life may depend upon the audible warning sound. In all cases, the equipment designer should consi-der the desired characteristics of the audible alarm at the initial design planning phase to obtain sati-sfactory performance and avoid costly redesign. The first characteristic for a designer to consider is the type of sound such as a continuous, intermittent, or specialty sound. Other critical criteria include sound level, frequency, current draw, quality, mounting configuration, cost, and availability.Even in this case the standard IEC 60601-1-8 comes to the rescue, defined visual and audible alarm cha-racteristics.

2. Methods: Determining Priority

Inadequate configuration and use of the alarm sy-stems lead to unnecessary alarms on the one hand and also result in critical situations not detected on the other hand. Therefore, a higher general aware-ness, and increased knowledge, of healthcare provi-ders regarding the function of the alarm system is of interest. Determining serious injury of the patient, probably could understand the exactly classification of visual alarm of the medical device. For determi-ning serious injury we start to study the typical sym-ptoms and sign of patient. In the chronic renal the-rapy typical symptoms and signs of injury are:

- Breath- Nausea- First use syndrome- Feel hot- Feel funny- Restless- Headache

probably these list of sign required immediate first aid to prevent serious injury and to mitigate the se-rious injury the machine raises an alarm. IEC 60601-1-8 gives guidance on whether a patient’s condition should be assigned a high, medium or low priority. This guidance is based on the potential result of a failure to respond to the cause of the alarm condi-tion and how fast the potential harm could happen to the patient. The alarm signals priority is the fol-lowing:

- low priority: operator awareness required;- medium priority: prompt operator response re-quired;- high priority: immediate operator response re-quired;- reminder signal: if alarms are inactive;- information signal: other than above and unli-kely to be covered by the standard.

17


IEC 60601-1-8 defines the different priority in the clause 201.1.2. The risk analysis determines the pri-ority of the condition based on severity and imme-diacy of required action.The standard does not specify whether or not there should be alarms. The circumstances which require alarms is not specified in the standard. Is not defi-ned the allocation of priorities alarms for specific alarm conditions or the technology that generates alarm signal.

Figure 1. Interface of dialysis system.

In the interface of the dialysis system figure (see Fi-gure 1) all the interface are shown graphically. One higherlevel interface is the graphical user interface used by the medical staff supervising the dialysis process. The user interface allows for the setting of the operational values, e.g. dialysis fluid temperatu-re and dialysis process characteristics, and provides accurate information about the system operation. Especially in case of alarm situations, the system should provide up-to-date information and allow for quick and accurate operation. Finally, the second hi-gherlevel supports the interaction with medical in-formation systems. This allow for the downloading of the patient information, including patient specific settings of the dialysis parameters.A first point of view of the alarms classification we should distinguish between the alarms of the dialysis fluid circuit and the extra-corporal circuit. In this case we separate circuits, because extra-cor-poral circuit is more highly prioritized for patient safety than the dialysis fluid. This choice is correct because during the alarms condition related to the fluid the machine goes in bypass state, safe state of the patient. But however an information signal may also be used to indicate the potential result of failure to respond in case of delayed or prompt or immediate potential harm of the patient. The poten-tial result of failure to respond of the nurse could

be classified as following:a- Onset of potential harm refers to when an injury occurs and not to when it is manifested;b- Having the potential for the event to develop within a period of time not usually sufficient for manual corrective action;c- Having the potential for the event to develop within a period of time usually sufficient for ma-nual corrective action;d- Having the potential for the event to develop within an unspecified time greater than that gi-ven under “prompt”.

In the following Table 1 the values present in the cells represent an example of alarm priority table that follows the previous (a) , (b), (c), (d) reasons:

It is possible to study different alarm priority table, based only choosing for comparison the operating time of the nurse. In this case the table could be the following:

Potentialresult of failu-re to respond

Death or irreversible injury

Reversible injury

Minor injury or discomfort

Immediate (b)(within seconds to a couple of minutes)

HIGH (a)

HIGH

HIGH

Prompt (c)(at least several to many minutes have elapsed)

MEDIUM

MEDIUM

MEDIUM

Delayed (d) (many minutes to hours)

MEDIUM

LOW

LOW

Onset of potential harm

Table 1. Example Alarm Priority Table.

Potentialresult of failu-re to respond

Death or irreversible injury

Reversible injury

Minor injury or discomfort

Immediate(within seconds to a couple of minutes)

HIGH

HIGH

HIGH

Prompt(at least several to many minutes have elapsed)

MEDIUM

MEDIUM

MEDIUM

Delayed (many minutes to hours)

MEDIUM

LOW

LOW

Onset of potential harm

Table 2. Example Alarm Priority Table.

18


The cell of the table represent the different alarm class decided. For each alarm class is defined a rule and the color to apply by the user interface (the color property is indicated in the Table 2). Another gene-ral rule could be that each alarm must be classified depending on the countermeasures applied by the machine (machine actions) after triggering that spe-cific alarm without considering connected/related alarms. The conditions which may cause “irreversi-ble injuries” that could continue after the machine action is applied will be classified high priority, be-cause only the operator response can stop injuries. Onset of potential harm refers to when an injury oc-curs and not when it is manifested. The standard ISO 3864-2:2004 (ANSI Z535.4-2002) is used to decide the design of safety signs for products but also as a starting point for the classification of the alarm. This standard declare that the classification of the alarms depends of severity of harm:

- death or serious injury; - moderate or minor injury.

Serious injuries typically have one or more of the following characteristics:

• result in permanent loss of function or signifi-cant disfigurement;• requires substantial and prolonged medical tre-atment;• involves considerable pain and suffering over long periods of time.

Examples of serious injuries include amputations, severe burns, and loss or impairment of vision or hearing. The standard use, the meaning of the different ha-zard severity panels as following:

- danger - indicates a hazard with a high level of risk which, if not avoided, will result in death or serious injury; - warning – indicates a hazard with a medium level of risk which, if not avoided, could result in death or serious injury;- caution – indicates a hazard with a low level of risk which, if not avoided, could result in minor or moderate injury.

2.1. Visual alarm signal characteristics

Visual alarm signals must at minimum alert the user to the presence and cause of an alarm condition and their priority according 201.3.2.1. Colour and other specific characteristics for visual alarms are in Table 3.

Where does the alarm indicate/annunciate?The standard specifies that the alarm indicate could be as following:• local (at device);• distributed (remote from device);• hardwired (e.g. hall way lights, nurse call);• RF (e.g. pagers, mobiles).In some cases may be both local and distributed. The important thing to underline is that only the risk analysis determines who needs to bealerted and lo-cations they are likely to be. The typical signal word selection process referring to ISO 3864-2:2004 is summarized in the following figure 2:

Alarm category

High priority

Medium priority

Low priority

Indicator colour

Red

Yellow

Cyan or yellow

Flashing frequency

1,4 Hz to 2,8 Hz

0,4Hz to 0,8 Hz

Constant (on)

Duty Cycle (on/off time)

20% to 60% on

20% to 60% on

100% on

Table 3. Alarm Indicator Light.

Figure 2. Signal Word Selection Process.

19


The Clause 201.3.2.2 requires that where the visual alarm is required to assure the operator will know which device or part of the device requires attention, the following characteristics must be provided:

- Indicate the priority of the highest active alarm;- Perceived correctly from at least 4m away.

This indicator is necessary for alarm system that are intended to be located in the proximity of the other alarm systems.The standard requires that visual alarms may be ge-nerated on displays and visual alarm “locator” light or symbol identifies the specific alarm (LED next to text, graphics display, etc.).Also defines that the light/symbol used to define the low priority and high priority may be perceived correctly from 1m away or the operator’s position (if defined). On visual alarm are some notes to specify:

• Determining that a visual alarm will be correctly perceived is based on:

- 20/20 vision;- viewpoint is operator’s position (if defined) or 30° cone from center of and horizontal to display or other visual indicator;- ambient light from 100 through 1,500 lx.

• It is acceptable to have a single visual alarm indi-cator if it meets all applicable requirements.

The guidance on visual signals advices to not use flashing text, because is difficult to read so should avoid. In case of the black text on white background or white text on black background the use of flashing text is allowed. We are needed of the audible and vi-sual alarm system above all:

- when alarm system is in proximity of other alarm system (i.e. in ER); - not needed when worn (i.e. pager); - as dictated by risk analysis.

The work involving human-machine interaction is complex, but is essential in the medical device de-velopment. In fact there is no doubt that there is a need for major research and development efforts for medical device alarm systems to ensure easy human-machine interaction to improve user greater satisfaction. The entire chain, starting with the se-lection of appropriate alarm settings for a patient, continuing with the signal acquisition and ending with the communication of the alarm message, needs to be carefully examined. The IEC 60601-1-6 (Usability) should be used when designing and must be used to validate visual signals:

- meaning will be understood;- priority will be recognized;- location and required action will be understood.

Finally, it is important to acknowledge that nurses are the best monitors. Providing them with the right tools, such as mobile decision support systems or personalized alarms, has high potential to improve their situational awareness and efficacy, thereby im-proving patient safety. Special care should be taken to avoid replacing experienced nurses with a combi-nation of less experienced healthcare providers and additional patient monitoring equipment.

2.2. Audible alarm Characteristic

How seen before the first step is to assign the prio-rity of the condition that is being monitored by the medical equipment then some characteristic requi-rements must be followed for the audible alarm. IEC 60601-1-8 gives guidance on whether a condition should be assigned a high, medium, or low priority.Audible alarm signals may be:

- prioritized and meet the characteristics defined in clause 201.3.3.1 to 201.3.3.3;- generated by other means (i.e. voice synthesi-zed), but these must be validated through ap-plication of 60601-1-6 (e.g. by clinical usability testing).

An important note is that the alarm system for high or medium priority alarm conditions that are not in-tended/likely to be continuously attended by an ope-rator in normal use should generate auditory alarm signals. For this consideration we understand that visual alarms are not adequate alone and many times an audible alarms in more than one location may be required.The audible alarm requirements is defined in the clause 201.3.3.1 that requires:

- sounds are priority encoded;- higher priority alarms must convey a higher sen-se of urgency;- validated (e.g. clinical usability testing) or fol-lows standard;- may provide means to store a set of auditory alarm signals in any alarm preset.

The clause also defines the characteristics for de-fined set of audible alarms, represented in the fol-lowing tables (see Table 4):

20


Table 4. Frequency and pulse alarm characteristics

Characteristic Value

PULSE FREQUENCY(f0) 150 Hz to 1,000 Hz

Number of harmonic components in the Minimum of 4 range 300 Hz to 4000 Hz

Effective PULSE duration (td)

HIGH PRIORITY 75 ms to 200 ms

MEDIUM and LOW 125 ms to 250 ms PRIORITY

RISE TIME (tr) 10% - 20% of td

FALL TIME(a) (tf) tf < ts – tr

NOTE: The relative sound pressure level of the harmonic components should be within 15 dB above or below amplitude at the PULSE FREQUENCY

a - Prevents overlap of PULSES

Characteristic

Number of PULSES in

BURST (a,e)

Between 1st and 2nd

PULSE

Between 2nd and 3rd PULSE

Between 3rd and 4th PULSE

Between 4th and 5th PULSE





Between 9th and 10th

PULSE

HIGH PRIORI-TY SIGNAL

10

x

x

2x+td

x

0.35 s to 1.30 s

x

x

2x+td

x

MEDIUM PRIORITY SIGNAL

3

y

y

Not applicable

Not applicable

Not applicable

Not applicable

Not applicable

Not applicable

Not applicable

LOW PRIORITY SIGNAL (d)

1 or 2

y

Not applicable

Not applicable

Not applicable

Not applicable

Not applicable

Not applicable

Not applicable

Not applicable

Where x shall be a value between 50 ms and 125 ms

Where y shall be a value between 125 ms and 250 ms

The variation of x and y within a BURST shall be +- 5 %

MEDIUM PRIORITY td+y shall be greater than or equal to HIGH PRIORITY td+x

a-See also Table 3 for characteristics of the PULSE

b-Unless otherwise specified in a particular standard for a particular MEDICAL ELECTRICAL EQUIPMENT

c-Manufacturers are encouraged to use the longest INTER-BURST INTERVAL consistent with the risk analysis. Writers of particular standards are encouraged to consider the longest appropriate INTERBURST the auditory ALARM SI-GNAL for the particular ALARM SYSTEM application. Long INTERBURST INTERVAL can under certain conditions ne-gatively affect the ability to correctly discern, in a timely manner, the source of the ALARM CONDITION.

d-The generation of the auditory component of a LOW PRI-ORITY ALARM CONDITION is optional.

e-Unless inactivated by the OPERATOR, MEDIUM PRIORITY and LOW PRIORITY auditory ALARM SIGNALS shall comple-te at least one BURST, and HIGH PRIORITY auditory ALARM SIGNALS shall complete at least half of one BURST.

Between 9th and 10th

PULSE

INTERBURST INTERVAL (b,

c) (td)

Difference in amplitude between any two PULSES

x

2.5 s to 15.0 s

Maximum 10 db

Not applicable

2.5 s to 30.0 s

Maximum 10 db

Not applicable

>15 s or no repeat

Maximum 10 db

Table 5. Signal time alarm characteristics.

21


Clause 201.3.3.2 has minimal requirements regar-ding sound pressure:

- lower priority alarms may not be louder than hi-gher priority alarms; - no requirements for minimum or maximum sound pressure level:

• 45 > 85 dB is generally reasonable;• should be based on background noise in use environment (documented analysis in RMF).

The audible alarm signals requirements in the time domain listed in IEC 60601-1-8 could be represen-ted as following:

Just for clarification but in this article does not de-epen the discourse the clause 6 of the standard hi-ghlights some rules to consider and to clarify in the instruction for use:

• overview of alarm system;• description of every possible alarm and, as appro-priate for the user, how it is determined;• inherent delays;• expected operator position;• how and when to verify alarm functionality;• caution against setting extreme limits.

Figure 3. Representation of the signal in the time domain.

Figure 3a. Example of the signal.

In the following table is the IFU content:

To end the overview of the audible alarm characte-ristic by standard is important to add some notes on melodies and Annex EEE. Meaning of melody is required to be consistent with the underlying alarm condition or equipment category and may be used only to indicate the defined conditions. Melodies other than those defined are acceptable if they can-not be confused with the defined melodies, or the defined alarm signals.The standard defines generic melody for general use as following:

Description Clause or subclause

ALARM SIGNAL GENERATION 201.4.2 b)DELAY OF DISTRIBUTED ALARM SYSTEM, maximumtime or time to TECHNICAL ALARM CONDITION 201.4.1ALARM SIGNAL GENERATION DELAY, mean

ALARM SIGNAL 201.4.1GENERATION DELAY, statistics of distribution

ALARM CONDITION DELAY, 201.4.1mean time

ALARM CONDITION DELAY, 201.4.1statistics of distribution

ALARM CONDITION log after 201.12 b)power down

ALARM CONDITION log after 201.12 c)power failure

ALARM CONDITION, grouping 201.1.1

ALARM CONDITION, priority 201.1.2of each

Table 6. Relationship alarm argument with clause or subclause.

Cause Low Priority

Any e c

Table 7. Generic melody.

22


The characters c,d,e,f,g,a,d,C refer to relative musi-cal pitches and C is one octave above c.An examples of the different melody are represen-ted in the following table:

All pulses and bursts shall comply with the timing and volume requirements of list element a) of 201.3.3.1. The melodies may be sounded in diffe-rent keys or octaves if the absolute frequency of “c” lies between 150 Hz and 500 Hz. The “General” burst may be used for any auditory Alarm signal in any alarm system. A High priority alarm signal is ge-nerated with the five pulses shown, repeated once, for a total of 10 pulses. There two type of exception on some technical alarms and a information signals. Audible alarms need not comply with the require-ments of clause 201.3 if they are technical alarms for indicating:

- power system failure;- alarm system failure.

Information signals are up to design team and are not regulated by the standard other than that it is not possible to confuse them with alarm signals. IEC 60601-1-8 requires that an individual sound pul-se must have a fundamental frequency (musically known as pitch) somewhere between 150 to 1000 Hz, and there must be at least four harmonic sounds from 300 to 4000 Hz as we can see in the following figure 4 :

Cause

General

Cardiac

Artificial perfusion

Ventilation

Oxygen

Temp/Energy delivery

Drug or fluid delivery

Equipment or supply failure

Medium Priority

c c c

c e g

c f# c

c a f

C b a

c d e

C d g

C c c

High Priority

c c c – c c

c e g – g C

c f# c – c f#

c a f – a f

C b a – g f

c d e – f g

C d g - C d

C c c – C c

Table 8. Alarms melody musical pitches.

The IEC 60601-2-16/ IEC 60601-1-8 standards im-pose some constraints on the sound pulses that bu-ild up an alarm sound, in terms of length, duration, rise/fall time, spectral content and sound power. We not expand on the frequency speech in this ar-ticle, but say that the sound of the alarm requires testing to be compliant to IEC 60601-1-8. According the standard the audio file (high, medium, low) from a spectral point of view, must be a minimum of 4 pulse harmonics in the range from 300 Hz to 4kHz, the fundamental frequency of the pulses must lie between 150 Hz and 1kHz, and the 4 harmonics must have an amplitude between +/- 15 dB from the fundamental.

3. A Software approach of intelligent alarm system The clause 201.2 describes intelligent alarm as:

• alarms threshold changes over time;• determines an alarm condition (multiple varia-bles, algorithms, fuzzy logic, etc.);• generates signals for multiple conditions of equal priority (ranking, effect on signal genera-tion, etc.);• changes delays (in recognition of or generation of alarm);• changes alarm signal characteristics (volume, pitch, etc.);

The intelligent alarm system is a quite complex pie-ce of software and are characterized by a higher degree of different functionality. It determines the different alarm condition and manages the different condition to raise an alarm. It has a graphical user interface to a dialysis machine and is able to descri-be generic information data using different kinds of widgets. Essentially the three major software subsy-stems are the General User Interface (GUI), the Con-trol System, and the Protective System (see figure 5).

Figure 4. Example of an audible sound that is compliance to standards.

23


The principal responsibilities of the GUI is to get user input (nurse) and to resend data and alarms. Also sends the treatment data and state of the machine at the control system and protective subsystem this allows to set protective and control mode in the cor-rect states/modes. The control system supervises the value set by the user according to the treatment selected for the time being and is responsible for maintaining/sending the correct values of the ma-chine to the other subsystem (coordinator). The control system and GUI collaboration is a tight-loop process control system that allow to the machine to change state and evolve. The responsible for detec-ting any hazard situation is the protective system. The protective subsystem, checks the set values and the current treatment values permitted in case of the patient might be hurt ensure the safe condition. It runs on a own tasks or process and is supposed to be as separate from the other parts of the system as possible. When detecting a hazard, the protective system raises an alarm and engages a process of re-turning the system to a safe-state. The protective lo-gic many time is redundant to ensure greater degree of security that is required by standard. Usually, the safe-state is stopping the blood flow or dialysis-fluid flow. The documented structure of the system is no more fine-grained than this and to do any change impact analysis, extensive knowledge of the source code is required. To achieve this requirements the application architecture will be executed in pseudo parallel. The device:

- collects the data;- normalizes it using the normalizer parameter;- calculates the new set values using the con-trol algorithm parameter (as described in clause 201.2).

The sequence control is implemented using periodic object pattern (see figure 6).

Figure 5. Component Diagram of intel-ligent alarm subsystem.

The protect system monitoring process independen-tly from other subsystem. If we think at the alarm monitoring process as a device that is monitoring by a second device (like supervisor), the Alarm Detector Device becomes a single atomic module, which is configured with a number of device-specific alarm situations has arisen. If it identifies an alarm situa-tion, it invokes the associated Alarm Handler which then takes care of the alarm. The alarm detector de-vice also is part of hierarchy of devices. If we want to obtain major abstraction on the Device/Control relations, the Alarm Detector Device represents a specialization of the Device archetype. Components of the Alarm Detector Device archetype is responsi-ble for monitoring the sub devices and make sure the value read from the sensors are within the alarm threshold value set to the Alarm Detector Device. When threshold limits are crossed an Alarm Handler component is invoked. The Alarm Handler is the ar-chetype responsible for responding to alarms by re-turning the haemodialysis machine to a safe-state or by addressing the cause of the alarm. Components are used to parameterize the Alarm Detector Device components (see figure 7).

Figure 6. Sequence diagram of the Con-trol Sequence.

Figure 7. Class Diagram of dialysis archetypes and their relation.

24


The control system may utilize Alarm Detector Devi-ce to detect problem situations. Assuming this type of architecture the protective subsystem is modeled as a device hierarchy. In this case the entities related to the hardware are modeled and complete system is easily interchangeable. Also is possible to define different controlling algorithm for every device. The device becomes either a leaf device or a logical de-vice.Each controlling algorithm with a normalize repre-sent a parameterized leaf device while more sub devices with the controlling algorithm and the nor-malizer object represents a logical device. The de-vice archetype stores the information relations and configuration about controlling algorithm while the controlling algorithm performs calculation for set-ting values of sub output device. The controlling al-gorithm gets values from input sub devices and the control receives the value from encapsulated device.So the computation is done in a separate archetype, which is used to parameterize device components. The object Normalizer is used to bring or make into the same units values different units of measure-ment. Also a normalization archetype is used to pa-rameterize the device components and as interface for the different input values. The previous archet-ype may use to model the application architecture of a haemodialysis machine (see figure 8).

This point of view represents the system with a la-yered view. The GUI subsystem is represented with Haemodialysis Machine (HDF) treatment, while the remains other components is in dashed region (Pro-tective System in red, Control System in blue, Control Hardware System in azure). The access to the device

is through interfaces to the lowest layer. This type of architecture is based pseudo parallel execution of the functionality. In the first step the device collects the data then the normalizer makes different units of measurement uniform, at last the new treatment set value using algorithm (see figure 6). The alarm devi-ces is used from the control system to detect alarm condition. The protective system could be seen as a group of alarm devices with different type of con-figuration. The process of alarm detect run perio-dically and the message to the control system of a new calculation of the set value is sent periodically (see figure 9).

Figure 8. Example haemodialysis Application Architecture.

Figure 9. Alarm Handler sequence diagram.

25


CONCLUSIONS

Starting from the requirements the evaluation of the software architecture is complicate without know the context of the application. In this paper first we tried to explain the salient features of IEC 60601-1-8. Then specified general requirements is given one software development that follows the object 60601-1-8. In this article treated only some aspects of the IEC 60601-1-8, highlighting some of the architectu-ral design of a haemodialysis system. The aim is to optimize the driving software quality requirements are maintainability, reusability, safety, demonstrabi-lity during architectural design. In the other hand provides some background to our experience. The software maintainability is difficult to evidence, but if the architecture easily incorporates new require-ments. Also the code is atomic when needed cor-rects the defects and to study unit test. Finally te-sting the causes the maintainability of the software developed is complete and reached high performan-ce. Starting from the study of the reference stan-dard the safety and demonstrability are conditions of the IEC 60601-1-8. The device archetype used to developed can be used again to add new functiona-lity with slight modification. The parameterization of the normalizer and controlling algorithm reduces the implementation time and increases the software reusability. The multi-layer architecture used makes simplest the reuse of lines of code with different de-vice and technology. There is no doubt that the sof-tware architecture with these requirements will add cost, but is always easy to change the design cycles of medical equipment. Also essential performance of medical electrical equipment and medical electri-cal systems that implement using these architecture is most efficiently. In the long run the manufacturer will gain a competitive advantage over their com-petitors and the time to improve new complete and safe features reduces.

GLOSSARY

Haemodialysis: is a Renal replacement therapy used to treat advanced and permanent kidney failure. The principle of Haemodialysis is to filter waste products from the blood and to restore normal constituents to it, involving diffusion of solutes across a semiper-meable membrane, where the dialysate is flowing in the opposite direction to blood flow in the extracor-poreal circuit.

Clause: in this use is smallest grammatical unit that can express a complete standard. More complex standard may contain multiple clauses, including clauses contained within clauses.

MDD: manufacturing Details Design describe the definitions for manufacturing or mechanical design choices. Also MDD is a roadmap or a strategic ap-proach as a manufacturing information of design and noun informally refers to a plan or convention for the construction of an object or a system.

LED: is a representation of 2 states (On/Off), in this case we are referring to GUI LEDs that are used as in-dicator lamps in many devices and are increasingly used for other lighting.

ER: in the USA represent Emergency Room in hospi-tals.

Pager: a pager (often called a beeper) is a simple personal telecommunications device for short alarm messages.

IFU: the act of using; the application or employment of something for a purpose, the word is an abbrevia-tion to indications for use.

API: an application programming interface (API) is a particular set of rules (‘code’) and specifications that software programs can follow to communicate with each other.

Periodic Object Pattern: a description of an object-oriented design technique which names, abstracts and identifies aspects of a design structure that are useful for creating an object-oriented design. An object has an internal state and provides a set of services and sometimes, the set value of the object ‘A’ may depend on the set value of object ‘B’. Whe-never ‘B’ changes, ‘A’ should recompute its state to remain in Sync with ‘B’.

26


Biography

Pasquale Sessa, since November 2008 works

at Altran Italia for the Energy Industries Life Sciences (EILiS) Division. He has been working as software and application technology in the field of biomedical with the Gambro Group since 2006 to present. The engage

as a consultant on behalf of the Research and Development department of this leader biomedical company led him to specialize increasingly in the management of complex biomedical projects and their staffs at international levels. He is graduated in Electronic engineering in 2003, University of Naples, with a master research investigated the automatic construction of multimedia serial devices. He have experience in: software development and design for embedded system and in the last two years is also developer of Human interface. He is a electronic engineer expert informatics and automatic measurement, interested in the construction and implementation of a novel experimental protocol in the biomedical field.

BIBLIOGRAPHY

[1]. IEC 60601-1-8 Ed. 1.0 b:2005, Medical electrical equipment - Part 1-8: General requirements for safety - Collateral Standard: General requirements, equipment and medical electrical systemsStandard IEC 60601-1-8, 2006[2]. ISO 3864-2:2004, Graphical symbols - Safety colours and safety signs - Part 2: Design principles for product safety labelsStandard ISO 3864-2:2004 [3]. The International Organization for Standar-dization http://www.iso.org[4]. Dan O’Brien, Outside Sales Engineer, Mallory Sonalert Products, Inc.Using Audible Alarms in Medi-cal Equipment (IEC 60601-1-8)[5]. Wirfs-Brock, B. Wilkerson, L. Wiener, Desi-gning Object-Oriented Software, Prentice Hall, 1990.[6]. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen Object-oriented modeling and design, Prentice Hall, 1991[7]. Jan Bosch Design and use of software archi-

tectures: adopting and evolving a product-line ap-proach, May 1999[8]. I. Jacobson, M. Christerson, P. Jonsson, G. Övergaard, Objectoriented software engineering. A use case approach, Addison-Wesley, 1992.

27

Date post:	29-Feb-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Guidelines for medical alarm system software...

Documents