RADIOPHARMACEUTICAL GENERATION SYSTEM
The present invention relates to a radiopharmaceutical generation system, and is particularly, but not exclusively, related to aspects of control thereof.
Background
Nuclear medicine involves the use of radioactive isotopes (radioisotopes) within a body. The radioisotopes are attracted to specific organs, bones or tissues, and the emissions produced by the radioisotopes are used provide information about a particular type of disease. Examples of radioisotopes commonly used in nuclear medicine include carbon-11, oxygen-15, fluorine-18 and bromine-75.
Positron emission tomography (PET) is an example of a nuclear medicine diagnostic technique whereby images of physiological function of organs are acquired by imaging the decay of radio-isotopes bound to molecules having known biological properties. Suitable radio-isotopes are synthesized into a carrier (also called a tracer) that enables the radio-isotope to be delivered to the organ being examined. Such a carrier is commonly referred to as a radiopharmaceutical.
One commonly used radio-isotope is Oxygen-15 (15O), which is produced by deuteron bombardment of natural nitrogen through the l N(d,n) 5O nuclear reaction; this process is carried out by a device commonly referred to as a cyclotron. The present invention is not concerned with the way in which the radio-isotope is generated, and the cyclotron will not be described in further detail.
One radiopharmaceutical associated with the Oxygen-15 radio-isotope is 15O-labelled water. Typically, 15O-labelled water is produced on-line from Oxygen -15 in a radiopharmaceutical generator by mixing Oxygen-15 with hydrogen, in a stochiometric proportion, and passing the mixture over a palladium catalyst in an oven at 150°C. The resulting radioactive water vapour
diffuses across a semi-permeable membrane (cellulose acetate) into a sterile saline solution (0.9% NaCl), which is pumped continuously through the system with a medical infusion pump to generate a solution containing 15O-labelled water. One radiopharmaceutical generator suitable for generating 15O-labelled water is described in an article entitled "Technical performance and operating procedure of a bedside [15O] water infuser", authored by H Touchon-Danguy et al and published in the Journal of Label. Cmpds. Radiopharm., volume 37 pages 662 - 664, in 1995. The radiopharmaceutical generator comprises several components, some of which are independent of, and others of which are interrelated with, other components. This means that, when there is a problem with the operation of the radiopharmaceutical generator, it is extremely difficult to work out where, in the radiopharmaceutical generator, the problem is. Typically, a technician has to test each and every component, which can be extremely time consuming and have a significant impact on operation of the whole PET facility. Moreover, if there is any risk of radioactivity leaks, the entire PET facility is shut down; since downtime associated with trouble-shooting is costly and inconvenient, being able to identify whether the entire facility requires shutting down becomes increasingly important.
The act of noting the progress of the fluid generation process is known from US 4,625,118, in which a photoelectric barrier is used to detect output of fluid from a syringe. In the US 4,625,118 system, once the presence of fluid has been detected, the configuration of certain valves is modified so as to adjust the fluid delivery path. Whilst providing a means of triggering a change to the flow delivery path (in this case enabling the fluid in the syringe to fill a flushing station), this does not provide any detailed information as to the operational status of the generator, and thus does not readily facilitate isolation of problems with devices therein. It would thus be desirable to provide a means of improving identification of faults associated with the radiopharmaceutical generator.
A second problem results from the fact that radioactivity is only measured within the radiopharmaceutical generator itself. The distance between the radiopharmaceutical generator and the subject being examined can be significant, due to logistical constraints (layout, shielding and safety requirements etc.). Thus by the time that the radiopharmaceutical is delivered to the subject, the actual level of radioactivity may be substantially different to the level measured in the radiopharmaceutical generator. For a radiopharmaceutical based on Oxygen-15, which has a half-life of 2 minutes, this distance, and thus decay in radioactivity, can be appreciable. It would thus be desirable to provide a means quantifying the level of radioactivity delivered to the subject.
Summary of the Invention
According to a first aspect of the present invention there is provided a radiopharmaceutical generation system comprising: a fluid processing system arranged to perform one or more processes in relation to a radiopharmaceutical, the fluid processing system having a plurality of system elements and being arranged to output signals indicative of a state of the fluid processing system, each of said system elements having an expected operative state; and at least one monitoring software component arranged to derive data from said output signals and to compare said derived data with one or more operating conditions in order to identify system elements not in the expected operative state. The fluid processing system may be a radiopharmaceutical generator, which, in one embodiment is a water generator, and the one or more processes may constitute a radiopharmaceutical generation event.
Since the expected operating state of system elements is monitored during a radiopharmaceutical generation event, real-time monitoring of the generator is possible. This means that fault finding and trouble shooting is easier than it is with current systems.
Conveniently, the or each system element is arranged to receive one or more control signals that have been issued by a controller, and said one or more processes (i.e. radiopharmaceutical generation event) are performed in accordance with said control signals. Additionally the controller is arranged to output data to the monitoring software component as it issues control signals to at least one system element. In one arrangement the controller comprises at least one software component.
Preferably the controller is arranged to receive said output signals indicative of the state of the radiopharmaceutical generation system, and it tracks the state of the radiopharmaceutical generator on the basis thereof. In response to a change in the state of the radiopharmaceutical generator, the controller is arranged to output data to the monitoring software component.
Advantageously the monitoring software component includes an outputting software component in the form of, for example, a display means or an alerting means. The outputting component provides a means of communicating said real-time state information to an operator of the radiopharmaceutical generation system.
In one arrangement, the radiopharmaceutical generation system elements include: a heating device; a radiopharmaceutical delivery system comprising an output to a subject (e.g. patient); a plurality of valves arranged to control the path of the delivery system; a dialyser; a pump for pumping the radiopharmaceutical around the delivery system; and at least one radioactivity detector arranged in the path of the radiopharmaceutical delivery path. The system elements are respectively operable to output signals indicative of at least some of: temperature of heating device; energised status of the valves; flow rate through, and pressure applied by, the pump; radioactivity measured by radioactivity detector; and time elapsed since the process started. In such an arrangement the monitoring software component is arranged to identify which of the processes is currently being performed on the basis of data identifying the energised status of the valves, and the display means is arranged to display a natural language descriptor corresponding to said identified process.
Alternatively, the monitoring software component is arranged to identify which of the processes is currently being performed on the basis of radioactivity data measured by the radioactivity detector, since the radioactivity detector is located in a specific part of the delivery path of the radiopharmaceutical. In the following description, a radiopharmaceutical generator is alternatively referred to as a radiochemistry module.
According to a further aspect of the present invention there is provided a radiopharmaceutical generation system comprising: a fluid processing system arranged to perform one or more processes in relation to a radiopharmaceutical, the fluid processing system having at least one actuator element capable of adopting a plurality of operating positions, the fluid processing system being arranged to determine a current operating position of the actuator element and to output a signal indicative of the determined operating position; and at least one monitoring software component arranged to process data derived from said output signal during execution of said one or more processes in order to identify a state of the fluid processing system.
In this aspect of the invention, the operating positions, or states, of actual devices are determined, which enables accurate pinpointing of faults, together with a means of proactively planning for part replacement. Examples of actuator elements include flow valves, pumping mechanisms, and the like.
According to a yet further aspect of the present invention there is provided a radioactivity detection system for use in relation to ' a radiopharmaceutical, the detection system comprising: a fluid processing module arranged to receive a radioisotope and to generate a radiopharmaceutical therefrom; a radiopharmaceutical delivery system arranged to deliver the generated radiopharmaceutical to a subject, the radiopharmaceutical delivery system comprising a delivery path operable between said fluid processing module and said subject; and
a radioactivity detector arranged to measure radioactivity in the delivery path and output a signal indicative thereof.
The fluid processing module may be a radiopharmaceutical generator, which, in one embodiment is a water generator, and is enclosed within a lead shielding. In a preferred aπ-angement, the radioactivity detector is located as close to subject as possible thereby quantifying initial radioactivity levels as accurately as possible. More specifically the radioactivity detector is conveniently located along the delivery path at a distance of between 5% and
50% of the delivery path length from the subject, more preferably at a distance of between 7% and 12% of the delivery path length from the subject, hi one arrangement, the radioactivity detector is located between 100 and 150 mm from the subject, the delivery path having a total length of approximately 1.2 metres; in a second arrangement the radioactivity detector is located between 300 and
350 mm from the subject, the delivery path having a total length of approximately 3.5 metres .
This measured data is then used in the post-processing of scanned images of the subject, thereby increasing the accuracy of quantitative measurements of biological activity of the subject.
Brief Description of Drawings
Figure 1 is a schematic diagram of the radiopharmaceutical generator with which embodiments of the invention inter-operate;
Figure 2a is a schematic diagram showing the valves of Figure 1 arranged in a first configuration; Figure 2b is a schematic diagram showing the valves of Figure 1 arranged in a second configuration;
Figure 2c is a schematic diagram showing the valves of Figure 1 arranged in a third configuration;
Figure 2d is a schematic diagram showing the valves of Figure 1 arranged in a fourth configuration;
Figure 3 is a schematic diagram showing a controller for the radiopharmaceutical generator of Figure 1 according to an embodiment of a first aspect of the invention;
Figure 4 is a flow diagram showing steps carried out by the controller of Figure 3 according to an embodiment of a first aspect of the invention;
Figure 5 is a schematic diagram of a GUI comprising part of the controller of Figure 3;
Figure 6 is a flow diagram showing further steps carried out by the controller of Figure 3; Figure 7 is a flow diagram showing yet further steps carried out by the controller of Figure 3;
Figure 8 is a schematic diagram of a GUI comprising part of the controller of Figure 3;
Figure 9 shows a schematic diagram of a nuclear medicine diagnosis facility according to a second aspect of the invention;
Figure 10 is a schematic diagram illustrating a holding device for a second detector according to the second aspect of the invention;
Figure 11 is a flow diagram showing steps carried out by the controller of Figure 3, which has been modified to process data in accordance with the second aspect of the invention; and
Figure 12 is a perspective representation of the radiopharmaceutical generator according to the first aspect of the invention, comprising a radiochemistry module.
Overview of Operating Environment of Embodiments of the Invention
Figure 1 is a schematic diagram of a radiopharmaceutical generator, which in this embodiment is a conventional water generator 100, showing a catalyst furnace (oven) 101 for producing radioactive water vapour (H2 O); a saline source 103; a dialyser (semi-permeable membrane) 105 for binding radioactive water vapour with saline; a pump 107 for pumping the saline into the dialyser 105 and towards subject 115; and a Geiger Muller (GM) tube 109 for measuring radioactivity in the saline radiopharmaceutical. Referring also to Figure 12, the radiopharmaceutical generator 100 is enclosed in a lead shield 1201, and includes a waste decay coil 1203 (shown schematically as waste 111 on Figure 1) that allows the radioactive water to decay before it exits the lead shield.
The radiopharmaceutical generator 100 also includes two operating valves, VI and V2, which control movement of fluid within the radiopharmaceutical generator 100. Referring to Figures 2a - 2d, the valves VI, V2 are configured such that the radiopharmaceutical generator 100 can operate in a plurality of modes (in the Figure, the pathway through the valve is indicated by an open quadrant). In a first mode, shown in Figure 2a (buildup: modei), VI is energised and V2 is de-energised. Thus in one direction Dl, saline is held in region 113 of the dialyser 105, thereby creating the radiopharmaceutical, and in another direction D2 saline passes out to waste 111. In a second mode, shown in Figure 2b, (infusion: mode2), VI is de-energised and V2 is energised, which means that the radiopharmaceutical present in region 113 is delivered to the subject 115 via delivery path 116, passing through the GM tube 109. In a third mode, shown in Figure 2c, (flushing: mode3), both VI and V2 are energised, and pure saline (from saline source 107) flushes out any radiopharmaceutical present in the radiopharmaceutical generator, the delivery tube 116 and in the subject 115 itself. In a fourth mode, shown in Figure 2d, (waste: mode4), both VI and V2 are de-energised, so that any remaining material exits via waste output 111. Preferably the valves include sensors (not shown), which sense whether or not the valves are energised.
Overview of Embodiments of the Invention
In the prior art, control of the radiopharmaceutical generator 100 shown in Figure 1 is either manual - by manually opening and closing valves VI, V2 - or automatic — by means of bespoke control unit. An advantage of controlling the radiopharmaceutical generator automatically is that various combinations of the modes described above (with differing intervals between successive modes) can be pre-programmed, and the timings can be accurately controlled. As a result, the valves can be controlled remotely, which, when the fluid involves radioactive material, is important from the point of view of health and safety.
However, in known automatic control arrangements, little or no information is fed back to the operator regarding the progress of generating and infusing the radiopharmaceutical into the subject. As a result, when there are problems with operation of the radiopharmaceutical generator 100, it can be extremely difficult to identify the source of the problem. Typically, a technician has to test each and every component, which can be extremely time consuming and have a significant impact on operation of the whole diagnostic facility. Moreover, if there is any risk to the patient, the entire diagnostic facility has to be shut down; since downtime associated with trouble-shooting is costly and inconvenient, being able to identify whether or not the problem will affect the patient, and thus whether the entire facility requires shutting down, becomes increasingly important.
Embodiments of the invention are thus concerned with improving speed and accuracy with which the source of the problem is identified. In one embodiment, the controller includes software components that send data to, and request data from, the various radiopharmaceutical generator components, and output, e.g. via a display, the data. Since the behaviour of these components can be well defined, the data received from the components can be compared with specified operating criteria, and/or simply displayed for inspection by an experienced operator.
Turning to Figure 3, an embodiment of the invention, for the case where the radiopharmaceutical generator is a water generator, will now be described in more detail. The controller of the radiopharmaceutical generator 100 comprises a programmable logic controller (PLC) 301 and a plurality of operational software components 311, which run locally on the PLC 301 in response to signals received from a conventional PC computer 320. The signals received from the PC 320 are generated under control of configuration software components 321. The operational software components 311 include software for controlling and retrieving data in respect of the radiopharmaceutical generator, and the configuration software 321 include software components arranged to receive operator-selected and/or operator-specified data, to send such data to the operational software 311, and to process data retrieved by the operational software 311. In one arrangement, the configuration software 321 is written using the Labview® programming language, but the skilled person will realize that any suitable computer programming language, or combinations of computer programming languages, could be used. The operational software 311 is written using the proprietary programming language associated with the PLC 301.
As shown in Figure 3, the computer 320 comprises processing unit (CPU) 323, memory 324, hard disc drive 325 and I/O device 326, which facilitates interconnection of the computer 320 with the PLC 301. Operating system programs 327 are stored on the hard disc drive 325, and control, in a known manner, low level operation of the computer 320. The computer 320 also includes a display and keyboard (not shown), which receive input from an operator and pass, via I/O device 326, the input to the O/S programs 327 in accordance with known techniques.
As also shown in Figure 3, the PLC 301 comprises: a bus 314, into which various operating modules can be plugged; a bus controller 315, which co-ordinates processing of data associated with the operating modules; and an I/O device 313, which is arranged both to receive input from external devices such as computer 320 and to output signals in accordance with operation of the
operating modules. In one arrangement, the input part of I/O device 313 comprises an RS232 interface which is arranged to receive input signals from the computer 320 (via serial link LI), and the output part of I/O device 313 has a plurality of output terminals, each being associated with a different one of the modules plugged into the bus 314 and connected to whichever component of the radiopharmaceutical generator 100 corresponds to that module. The bus controller 315 is arranged to receive data from the RS232 interface, process the received data in accordance with the operational software 311, and distribute data to an appropriate module on the bus 314. An example of a suitable PLC 301 is the Beckhoff™ PLC (model BC8100); the skilled person would realize that other types (notably those manufactured by Siemens™ or a bespoke PLC) could be used. The operating modules that plug into the bus 314 are not shown in Figure 3, but include: a module for controlling the temperature of the catalyst furnace 101; a module for controlling valves VI, V2; a module for controlling and monitoring pump 107 and receiving data therefrom; and a module for receiving data from the GM tube 109. When the valves VI, V2 include sensors indicating their energised state, the bus 314 also includes a module for receiving status data therefrom.
The functionality associated with energising and de-energising valves VI and V2 is conventional. However, other aspects of the operational software 311 are new, as are aspects of the configuration software 321 for processing operator-selected and/or operator -specified data. In particular, the configuration software 321 includes a graphical user interface (GUI), which can be used to specify operating parameters such as time intervals between mode changes (i.e. valve energizing and de-energising, Figures 2a - 2d); details of a radiopharmaceutical generator event; details of data to be retrieved from the radiopharmaceutical generator 100; and authentication criteria. These data, once entered via the GUI, are sent to the operational software 311 (as will be described in more detail below), which is arranged to transmit corresponding control signals to the radiopharmaceutical generator 100 in order to execute a radiopharmaceutical event.
The operational software 311 is also arranged to inform the configuration software 321 of the transmission of such control signals via confirmation signals and/or to initiate requests for data from components of the radiopharmaceutical generator during execution of the radiopharmaceutical event. When the operational software 311 requests data from components of the radiopharmaceutical generator, any data received in response thereto are forwarded to the configuration software 311 for post processing thereof, alongside, or in addition to, the confirmation signals received from the operational software 321. Such post-processing facilitates monitoring of real- time performance of the radiopharmaceutical generator and validation of radiopharmaceutical generator events, as is described in more detail below.
Firstly, however, steps involved in configuring a radiopharmaceutical generator event according to an embodiment of the invention will be described, with reference to Figures 4 and 5. Figure 4 is a flow diagram illustrating these steps and Figure 5 is a schematic diagram showing an example of a graphical user interface forming part of the configuration software components 321. Turning to Figure 4, at step 401, an operator enters data relating both to the subject 115 and to the radiopharmaceutical generator event. This information includes the names of the subject 115 and of the clinician responsible for the radiopharmaceutical generator event, and authentication data. Preferably this information is entered via text entry boxes 501, 502, 503, 504, 505 of the GUI, shown in Figure 5. In addition, the operator reviews calibration values relating to components of the radiopharmaceutical generator on a separate screen, accessible via tab 511. These calibration values include background radioactivity levels and are typically read from the database DB, to which only authorized users have access. In the event that the calibration values do not represent current conditions, the operator can request such an authorized user to change the values in the database.
The operator then selects 403 one of a plurality of operating protocols, e.g. from a drop-down menu that is displayed when the cursor hovers over a particular region 506 of the GUI. Each protocol typically represents a
configuration of the afore-mentioned valve modes (modei - mode4), together with temporal data relating thereto, and corresponds to a type of radiopharmaceutical generator event. The GUI includes an "operate" button 507, which the operator presses to request the start of a radiopharmaceutical generator event. The configuration software 321 includes a verification software component (not shown), which is arranged to verify that data have been entered into particular boxes of the GUI; the start button 507 is disabled by the verification software component until certain conditions have been satisfied (e.g. data entered into certain boxes 501 ... 505 etc.). In response to activation of the "operate" button 507, the configuration software 321 validates 405 the entered authentication data, e.g. by comparing the entered authentication data with an expected entry, which may be stored in validation database DB. Assuming the authentication data to be successfully validated, the configuration software 321 stores 407, locally, the data entered at step 401, and then formulates 409 a confrol string SI for input to the PLC 301. Since in this embodiment data are transmitted via the serial port of the computer
320, the control string SI takes the form of a comma delimited hexadecimal string. The control string SI includes data identifying the protocol selected at step 403, together with a request for data relating to at least one of: time since commencement of the radiopharmaceutical generator event; valve status set by the operational software 311; actual status of one or both valves VI, V2 (detectable via the sensors associated with the valves); protocol applied by the operational software 311; furnace 101 temperature; and radioactivity measured by GM tube 109. The request data can be specified either via the GUI, or via data stored in the database DB, or hard-coded into the configuration software
321. At step 411, the configuration software 321 outputs the control string SI, asynchronously, via the DO device 326. Configuration software 321 is then effectively "paused" until such time as data are received from the PLC 301.
Turning now to Figure 6, which is a flow diagram showing steps involved in processing a radiopharmaceutical generator event, aspects of the operational software 311 will now be described. The control string S 1 sent at
step 411 is received by the operational software 311 and processed (step 601) to extract information therein. The extracting step 601 involves decomposing control string SI into its constituent parts and converting to Boolean or numerical data as required. For illustrative purposes it is assumed that the protocol selected at step 403 corresponds to the following sequence: 120 seconds buildup (mode^; 20 seconds infusion (mode2); 120 seconds flush (mode ), and that the request part includes requests for all data that can be monitored during the sequence. Accordingly,' having decomposed control string SI, the operational software 311 firstly runs 603 an initialization process, which involves checking the temperature of the furnace 101 (since if the furnace temperature is not sufficiently hot, the radiopharmaceutical generator event cannot be processed), de-energising the valves VI, V2, and requesting the operating module corresponding to the valve sensors to record, via its own internal clock, the periods in which each valve is energised and de-energised. Assuming the temperature of the furnace to be within certain specified operating limits, at step 605 the operational software 311 initiates the processes associated with model5 which involves setting a timer tl, sending a signal to the operating module associated with the valves VI, V2, causing VI to be energised, and noting the time at which the valve is so activated. After 120 seconds have elapsed, the operational software 311 changes mode (steps 609,
610, 611, 605), sending a signal to the same operating module, which causes VI to be de-energised and V2 to be energised (setting mode2). After 20 seconds have elapsed, the operational software 311 again changes mode (steps 609, 610,
611, 605), sending a signal to the same operating module, which causes VI to be energised (setting mode3); and after a further 120 seconds have elapsed, the operational software 311 yet again changes mode (steps 609, 610, 611, 613 (since the condition at step 611 is, on this cycle, satisfied)), sending a signal to the same operating module, this time causing both valves to be de-energised (setting mode4). During these time intervals, the operational software 311 sends signals to various operating modules (plugged into the bus 314 of the PLC 301) requesting
items of data relating to their operation. Each data item corresponds to a part extracted from the control string SI at step 601, namely value of timer tl (time elapsed since start of radiopharmaceutical generator event); actual status of the valves retrieved from the valve sensors (energised or de-energised); temperature of the furnace 101; and number of counts recorded by the GM tube 109. Data items received in response to these signals are, under certain conditions, sent to the configuration software 321. In one arrangement, the operational software 321 monitors (step 607) the values of the requested data items, and, each time a value of a requested status data item changes, it creates a comma delimited hexadecimal return string S2 comprising the or each data item into and sends the return string S2 to the RS232 I/O port 313 for receipt by the configuration software 321 (step 608). In addition, each time the operational software 311 transmits a control signal. to a component of the radiopharmaceutical generator - e.g. one of the valves - it generates a return string S2, so that, at the very least, a return string S2 is sent each time the operational software 311 attempts to instigate a mode change.
If the value of one of the data items has not changed since the last time data was sent from the PLC 301, the portion of return string S2 corresponding to that data item assumes its previous value. Thus, during the first mode (Figure 2a), when the saline passing tlirough the GM tube 109 is not radioactive, the GM tube 109 is unlikely to register a change in level of radioactivity. Thus if one or more return strings S2 are sent to the configuration software 321 during this period (due to, e.g. a change in temperature of the furnace 101, or in the event that the actual status of the valve changes) the values relating to the GM tube 109 of successively transmitted return strings S2 are likely to be identical, or at least very similar, to one another. However, during the second mode (Figure 2b), when the radiopharmaceutical in region 113 is transported to the subject, the level of measured radioactivity (thus part of return strings S2 corresponding thereto) can be expected to vary. Since return string S2 is transmitted during a radiopharmaceutical generator event, the present
embodiment makes real-time monitoring of the radiopharmaceutical generator possible.
The configuration software 321 can alternatively or additionally send explicit data requests (via request string S3 shown in Figure 3) to the operational software 311, which causes the operational software 311 either to create return string S2 using the data items currently available, or to send requests for the data items to the various operating modules and create a return string S2 using the data sent in response thereto.
As a further alternative, the operational software 311 can create and send a return string S2 to the configuration software 321 periodically. In this arrangement the configuration software 321 is configured to poll for such a return string S2 with corresponding periodicity. In the event that the configuration software 321 cannot identify a return string S2 at an expected time, the configuration software 321 is arranged to generate an alert, which may be output, e.g. via the GUI.
Turning now to Figures 7 and 8, which are respectively a flow diagram showing steps involved in post-processing return string S2 and a schematic diagram showing output displayed by the configuration software 321, postprocessing of the return string S2 will be described. When a return string S2 is received at I/O port 326 of the computer 320, the configuration software 321 firstly performs 701 an error check, and, if the error check is successful, breaks 703 the return string S2 down into constituent parts and converts 705 the constituent parts to boolean or integer/non-integer values in accordance with a specified set of conversion rules. The error check involves, for example, checking the length of return string S2 against a specified length. As described above, each of the constituent parts corresponds to a data item - status of the valves VI, V2, temperature of the furnace 101 and/or radioactivity measured at the GM tube 109 etc. - which is subsequently processed by the configuration software 321 in order to assess the operating status of the various components of the radiopharmaceutical generator. In one arrangement, the set of rules includes one or more rules corresponding to each of the data items in the return string S2,
namely valves (actual status and protocol applied), GM tube measurements, oven temperature, etc.; for clarity, the following passages will describe postprocessing of individual data items in turn.
Considering firstly post-processing of data relating to valves VI, V2, step 706 includes identifying whether the return string S2 comprises one or both of actual valve data sensed by the valve sensors or/and confirmation of control signals sent by the operational software 311. In the event that both actual and confirmation data are available, the mode of operation corresponding to each type of data, together with a "natural language" description thereof, are identified (step 707) from a stored mapping (not shown) between mode and description (buildup: mode^ infusion: mode2, flush: mode3, waste: mode4). In the event that there is correspondence between the mode identified from the valve sensor data and the mode identified from the confirmation of control signal data, the natural language description identified at step 707 can be displayed 709 on the GUI of the configuration software 311 (box 531), for inspection by an operator. Monitoring actual, or real-time, status of the valves
VI, V2 thus enables the operator to track the progress of a radiophannaceutical generator event. In the event that the modes do not agree, an alert is generated.
If available, the actual times at which the valve sensors ascertained changes in valve state can also be displayed (not shown), and/or used to quantify any latency in the PLC 301 and/or operation of the valves (since the operator can compare an expected duration, specified in the protocol selected at step 403, with the actual duration (steps 611, 613), and, in the event that the actual duration fails to meet certain conditions (indicating, for example, a failed valve), generate an alert). In the event that the return string S2 only comprises confirmation of confrol signals sent by the operational software 311, there is no post-processing of temporal data, and the natural language description of operational mode coπesponds to that identified from the confirmation data alone. Referring also to Figure 7, and considering next the post-processing of data relating to the catalyst furnace 101, having extracted temperature data from
the return string S2, the configuration software 321 applies 721 rules to identify whether the temperature is within a specified operating range and displays 723 the temperature (box 801) on the GUI; in the event that the temperature falls outside of the specified operating range, the configuration software 321 constructs and displays an alert (steps 725, 727). Step 723 can also include storing the value of the temperature data item, which provides a means of tracking historical temperature values.
Considering next the post-processing of data from the GM tube 109, step 731 includes applying a coπection to the measured radioactivity data item values in order to compensate for measurement errors and levels of background radioactivity. This step therefore involves retrieving the calibration and background values selected at step 401 and applying them to the radioactivity values extracted at step 705 in order to identify a corrected level of radioactivity. This corrected level is then displayed 733 in real-time on the graph area 521 shown in Figure 5 as a function of elapsed time tl (itself displayed in box 533, shown in Figure 5); successively received return strings S2 thus provide a means of tracking the change in radioactivity associated with the radiopharmaceutical generator in real-time (since these values are plotted on graph area 521), as well as monitoring the magnitude of radioactivity infused into the subject 115. Thus the above described embodiment enables the operator to monitor both the operation of components of the radiopharmaceutical generator 100 and the progress of a radiopharmaceutical generator event. This enables prompt identification of problems, which in turn facilitates evaluation of the affect of the problem on the subject and isolation of the component(s), and only that/those component(s), responsible for the problem. This reduces the possibility of a potentially dangerous event becoming an actual danger, reduces time spent investigating the source of the problem, and thus reduces the downtime of a PET facility.
As stated in the introductory section, a further problem with current radiopharmaceutical generators is that the level of radioactivity is only measured at the radiopharmaceutical generator itself. As is well known, the decay of a
radio isotope is determined by its half-life, and decays exponentially. The decay of the radio-isotope within a subject (measured by the PET facility, and which is not a concern of this invention) includes a contribution from its half-life and a contribution from any biological effect resulting from the radio-isotopes binding with molecules of the subject. In order to ascertain the biological effect, the decay resulting from the half-life of the radio-isotope has to be removed from measurements, and thus firstly requires quantifying. Referring to Figure 9, the radiopharmaceutical generator 100 and the subject 115 can be separated by a reasonable distance, so that it takes a certain amount of time for the radiopharmaceutical to travel from the radiopharmaceutical generator 100 to the subject 115. As a result, the level of radioactivity measured by the detector 109 within the radiopharmaceutical generator 100 is unlikely to be indicative of that infused into the subject.
If the level of radioactivity measured within the radiopharmaceutical generator is then used to represent the half-life, the apparent magnitude of the biological contribution is likely to be lower than its actual value, since the level of radioactivity in the radiopharmaceutical generator can be expected to be higher than it is at the subject. For a radio-isotope such as Oxygen-15 this can be significant, since the half-life of Oxygen-15 is only 2 minutes. Referring again to Figure 9, in a second aspect of the invention, the radiopharmaceutical generator 100 includes a second radioactivity detector 901, which may be another GM tube or other suitable device, positioned in the vicinity of the scanner 903 of the PET facility. This facilitates measurement of radioactivity as close to the subject 115 as possible, thereby improving quantitative measurements of a subject's biological properties. In one arrangement, for a delivery tube 116 of length 1200 mm, the second radioactivity detector 901 could be positioned between 100 and 150 mm from the point of entry into the subject.
If the radiopharmaceutical were infused into an arm, the detector 901 could be located proximate to the delivery tube 116 at the patient's arm. A suitable holding device 1001, such as that shown in Figure 10, could be used to
secure the detector 901 in place; as can be seen, the delivery tube 116 passes through opening 1000 of the holding device 1001 and is thus exposed to the detector 901. The holding device 1001 includes a plate 1003 for securing the device 1001 to the scanner 903, via holes 1005. A data output of the second detector 901 can be coupled to the PLC 301 via a data link and further operating module (not shown), which is configured to receive and request data from the detector 901. Alternatively, the operating module corresponding to GM tube 109 can be arranged to communicate with both the GM tube 109 and the detector 901. Either way, the return string S2 generated by the operational software 311 will be created as described above, and in this second aspect of the invention will include data from both the GM tube 109 and the detector 901. This means that the configuration software 321 has to carry out some processing steps not described in Figure 7. These steps are shown in Figure 11 ; those that are common to both aspects of the invention are referred to using the reference numerals introduced in Figure 7. Initially, therefore, as for the first aspect of the invention, at step 701 the configuration software 321 performs an error check, and, if the error check is successful, breaks 703 the return string S2 down into constituent parts, converting 705 the constituent parts to boolean or integer/non-integer values in accordance with a specified set of conversion rules. At steps 1101a, 1101b the radioactivity data items corresponding to the detectors 109, 901 are corrected to account for background and calibration adjustments (note that if the detectors are of different types, the background and calibration values specified at step 401 are likely to differ). Since the detector 901 is measuring the radioactivity values close to the subject 115, these corrected values are displayed (step 1102) in the graph area 521 and are output for further processing to a processing part of the PET facility (not shown).
In addition to facilitating an improved quantification of the biological contribution to any measured decay (measured by the PET facility), these additional data can be used to monitor the behaviour of the radio-isotope and verify operation of the detectors 109, 901. Accordingly, in one aπangement, the
radioactivity values measured by the GM tube 109 are adjusted to take account of the distance between the two detectors, in order to estimate an expected level of radioactivity at the second detector 901 (step 1103). This expected value is compared (step 1105) with the actual value measured by the second detector 901, and, if the difference between the expected value and the actual value measured by second detector 901 exceeds a specified threshold, an alert is generated (step 1109). Since, at this stage, it is unclear which of the detectors 109, 901 is incorrect, the alert is passed to the processing part of the PET facility as well as to the operator of the radiopharmaceutical generator 100 (e.g. via the GUI).
Whilst in the first aspect of the invention a specific protocol (radiopharmaceutical generator event) involving 120 seconds build-up/ 20 seconds infusion/ 120 seconds flush is described, other protocols are possible. These are selectable from the pop-up menu 507 and include (non-exhaustive list):
1. 120 second build-up / 20 second infusion / 120 second flush;
2. 120 second build-up / 20 second infusion / 50 second flush;
3. 120 second build-up / 20 second infusion / 20 second flush;
4. Activity test: As 1 but V2 permanently to waste to check radioactivity level;
5. Sterilise mode: step through all 4 combinations of VI and V2 allowing all paths to be cleaned;
6. Long flush: permanently energise V2 while stepping VI between its 2 states; 7. Take samples: energise V2 for 30 seconds, de-energise for 1 minute, energise both VI and V2 for 30 seconds;
8. Energise VI and V2 for 50 seconds to fill the line to subject with fresh saline;
9. Turn oven heater ON or OFF as required during maintenance; 10. Turn valves VI and V2 ON or OFF as required during maintenance; and
11. Terminate mode: valves V 1 , V2 OFF.
Whilst in the above embodiments the connection between the PLC 301 and the PC is described as being a serial link, the connection could alternatively be wireless, e.g. Bluetooth or WLAN. Whilst step 401 involves manually entering data into the GUT, identification data could instead be stored in a log file, or similar, and read therefrom when the GUI is invoked.
Whilst in the embodiment relating to the first aspect of the invention described above, the operating software 311 requests data from the valves VI, V2, GM tube 109 and the furnace 101, the operating software 311 may also request data items in respect of the pump 107. Specifically, in the event that the pump 107 is equipped with means for measuring pressure and mass flow rate of the saline pumped therethrough, the operating software 311 may receive the flow rate and pump pressure data (e.g. via another module on bus 314) and include these data in the return string S2. Processing of a return string S2 comprising the pump data would then involve monitoring a change in flow rate over time, and, if the change satisfied certain conditions, the configuration software 321 would create an alert message that includes the option of generating a "stop" radiopharmaceutical generator event. In addition, the pump pressure would be monitored over time, and, if a specified rise in pump pressure were accompanied by a specified drop in flow rate, the operator would similarly be sent an alert message (and possibility of halting the radiopharmaceutical generator). This is particularly useful since a drop in mass flow rate accompanied by a rise in pump pressure may signify either a blocked pipe (harmless) or some reaction by the subject 115 as saline is infused therein (potentially harmful). This feature of the invention thus enables the operator a) to know that a problem exists that may affect the subject 115; b) to shut down the radiopharmaceutical generator 100; c) pinpoint the source of the problem accurately and d) investigate the source of the problem far earlier than is cuπently possible.
It will be understood that the present disclosure is for the purpose of illustration only and the invention extends to modifications, variations and improvements thereto.