WO2000069340A1

WO2000069340A1 - System for handling operating parameters for a diagnostic ultrasonic system

Info

Publication number: WO2000069340A1
Application number: PCT/DK2000/000266
Authority: WO
Inventors: Henrik Jensen
Original assignee: B-K Medical A/S
Priority date: 1999-05-17
Filing date: 2000-05-17
Publication date: 2000-11-23
Also published as: AU4538100A; DK199900676A

Abstract

System for handling the operating parameters for a diagnostic ultrasonic system comprising an ultrasonic transducer (12) emitting acoustic signals to the surroundings and receiving return signals from said surroundings, said ultrasonic system comprising a set of operating parameters. During operation the transducer (12) communicates with a console (1). At the delivery of a new transducer it was previously necessary to replace the associated console (1) because the operating parameters in question were held in the console (1). This draw-back is according to the invention set right by some of the data previously held in the console (1) now are held at the transducer (12) in such a manner that the console (1) can be maintained in case the transducer is to be replaced. The resulting system is much more flexible than hitherto known systems.

Description

Title: System for handling operating parameters for a diagnostic ultrasonic system

Technical Field

The invention relates to a system for handling the operating parameters of a diagnostic ultrasonic system comprising an ultrasonic transducer which emits acoustic signals to the surroundings and receives return signals from said surroundings, as well as an associated console, said ultrasonic system comprising a set of operating parameters.

Background Art

During the operation the ultrasonic transducer communicates with the console.

Previously, the delivery of a new transducer required a replacement of the associated console too because the operating parameters in question were encoded in said console.

Brief Description of the Invention

The object of the invention is to show how it is possible to avoid a replacement of the console in connection with a replacement of the ultrasonic transducer. A system of the above type is characterised in that data concerning the operating parameters have been placed at the transducer and can be transferred to the console, said operating parameters for instance including the module type of the transducer, the parameter values, the calibration data etc. The resulting advantage is found in the calibration data of the transducer automatically being fed to the console when said transducer is connected to the console. Such an interactivity presents further the advantage that it is possible to slack off the production accuracy of the transducer as it is possible with respect to software to compensate for possible production inaccuracies. In addition, an improved utilization of the transducers in question is obtained, and a few extra dB are obtained In other words a highly flexible system is obtained.

According to a particularly advantageous embodiment of the invention the data are placed in a PROM communicating with the plug-in member at the end of the connector for the transducer.

The data in the said PROM may advantageously communicate with a transducer test system, which in turn communicates with a database. As a result, the transducer test system can program the said PROM.

Finally a first portion of the operating parameters may according to the invention be placed at the transducer whereas another portion of said operating parameters can be collected from the console.

Brief Description of the Drawings

The invention is explained in greater detail below with reference to the accompanying drawings, in which

Fig. 1 illustrates a system for handling transducer data,

Fig. 2 shows a summary of categories of transducer data,

Fig. 3 shows a flow chart for the processing of the transducer data,

Figs. 4 to 6 illustrates a procedure for deciding whether transducer data from the PROM or a database are to be used, and

Fig. 7 shows an associated information structure diagram. Best Mode for Carrying Out the Invention

Fig. 1 shows a console 1 in connection with a data handling system 2, 3, 4, which can handle the majority of the transducer-related data used by a console 1. The transducer setup data are handled in another system.

The data handling system 2, 3, 4 comprises a database 4, a PROM 2 and a transducer test system 3. The console 1 receives transducer data from both PROM 2 and from the database 4.

In order to ensure an agreement and a control it is important that the handling of the transducer data is centralized. The centralization is obtained by means of a central database called the mother database 4 serving to store transducer data.

The mother database 4 transfers the transducer data necessary for the hardware/software combinations of the console 1 being supplied with data, to console-specific databases. The console-specific databases are referred to as child databases 7. A child database 7 is for instance provided for each of the console types 2400, 2101, 2102 and possible future console types.

The above PROM 2 is positioned in the plug-in member of the connector of the transducer 12 and includes data applying to the transducer.

The transducer data are handled by the transducer test system 3, for instance of the type 1150004 serving to program PROM 2 in the connector, for instance in the connector for for instance 86 xx and 88 xx transducers. The transducer test system 3 measures the characteristic properties of each transducer and communicates with the mother database 4 and PROM 2.

An immersion tank system 5 connectable to the data handling system 2, 3, 4 is used for measuring the intensity and the power of each console and transducer combination and for transferring transducer data to the mother database 4.

The transducer data are transferred in relatively large blocks and can be categorized as indicated in Fig. 2:

1. Data for identification of model, version, serial number and production date of the transducer.

2. Transducer specifications: Data relating to a specific transducer model.

3. Calibration data: Data relating to a single specimen of a transducer model or more specifically to a single acoustic module.

4. System data: Data relating to a combination of a transducer and a console.

5. Other data, such as graphic information for generating puncture lines and indications.

More categories can optionally be added.

A console 1 must have access to specifications of a transducer 12 in order to operate said transducer in a correct manner. In order to operate said transducer in a reliable manner within prescribed limits, the console 1 must furthermore have access to system data indicating how said transducer 12 operates from the console 1. When the console 1 has taken the calibration data into account, it can compensate for individual differences and operate in an optimum manner.

The transducer identifications including an identification of the transducer specimen are generated by means of the transducer test system 3, which includes its own registrations and enters data in the PROM 2 of the transducer.

The transducer specifications are entered manually at 6 in the mother database 4 which holds the specifications of the model and the data versions.

Calibration data are generated by means of the transducer test system 3 and stored in a local test database 11 and in PROM 2.

System data are generated by way of type test and automatically entered in the mother database 4, from which they can be transferred to the child database 7 in the console 1. They can also be transferred to PROM 2 through the test system 3. Subsequently, console software can be retrieved either from the child database 7 or from PROM 2. During the generating of system data, a set of specifications are used. However, the system data can only be used in connection with specifications which are compatible with the specifications used during the generating of the system data.

Other data, such as puncture lines are also entered in the mother database 4 and can be found in both the child database 7 and in PROM 2.

The data flow is shown in Fig. 1. However, Fig. 3 shows a more detailed illustration of the data flow because this Figure also shows the relations between the mother database 4 and the child databases 7 and the surroundings. Automatic inputs are mainly composed of data from the immersion tank system 5 in connection with the collection of system data, viz. the intensity and power measurings.

The complexity of organizing the transducer data is due to the many user relations between the consoles and the transducers. All the consoles can use a high number of transducers, and all the transducers can be used in connection with a high number of consoles. In addition, both transducer models and console models are available in a high number of versions, which in turn requires various software versions. Versions and compatibility

Two versions are associated with each set of categories shown in Fig. 2.

Nersion 1. The version of the component which the data tell something about.

Nersion 2. The version of the data identified through a contents version number.

For some data set there are even more versions as more objects may be involved. System data include for instance also versions of the consoles 1.

The version numbers are in two parts, a major part and an minor part. The minor part is used to register changes which are of so little significance that the changed part is directly backward compatible. The major part is incremented when this is not the case and something must be done to take the change into account.

Console identification ID is a combined key for both console model and the major hardware version. A console type 2400 in the hardware version 2.4 can have a console identification ID of 2400.002. The console minor hardware version is used to mark changes to the console hardware, which is estimated not to influence the acoustic output of the system. Correspondingly, the console hardware is designated by a major console software version and a minor console software version. The major console software version reflects major changes with respect to the transducers, whereas the minor console software version reflects what at first hand is esti- mated to be irrelevant in the transducer context (but not for the user).

The transducers are identified by their model designation, such as 8664.

Acustic modules have a module ID, which combines the model designation of the acoustic module (which most frequently corresponds to the transducer type and the major hardware version of the module, such as 8664.001).

A minor acoustic module hardware version exists corresponding to the minor console hardware version.

A software version for an acoustic module is implicitly contained in the contents version of the blocks, i.e. when the correction of the "soft" parameters of an acoustic module is included (it has for instance been observed that the expected radius of curvature is not true and this causes a lack in performance) this is handled by increasing the major contents version and adding new relevant data.

Data for identification of version

The actual data are related to the contents version. The higher the contents version is the newer the data are. The contents version is divided into a major contents version CMNers and a minor contents version CMiNers.

The major content version CMNers is incremented when the contents of the trans- ducer data have been changed and this must be taken into account (the change is non-backward compatible).

The minor contents version CMiNers is incremented when a change has occurred that still ensures backward compatibility (for instance a correction of a misspelling of a text-string associated with a puncture line or a data value/number that must be cor- rected but still ensures backward compatibility).

When choosing whether data are to be used from PROM 2 or the child database 7, these contents versions are used during the selection procedure illustrated in Figs. 4 to 6. For the consoles 2101 and 2102 not fully exploiting the PROM contents, the contents versions are without importance in practise. However, for the 2400 console, the contents versions are used during the selection process between data from PROM 2 and data from the child database 7.

Component relations

Although the data stored in the PROM at a transducer are exclusively to describe this particular transducer, the system must as a unit be able to handle the complexity due to the fact that various types exist. A transducer type can have one or several acoustic modules, it can exist in numerous variants, it can be mechanical or electronical, it can have various orientations, and it can be associated with various equipment.

This complexity has been handled by the design of the mother database implementing the structure shown in the information structure diagram of Fig. 7 and briefly described below.

Fig. 7 shows an information structure diagram of the interrelations between the components of the system according to the invention. The component is shown by means of solid lines, and the attributes or properties of the component are indicated by thin lines. The central component of Fig. 7 is Acoustic Module 701 communicating with the other modules in the manner described below.

Acoustic Module 701 comprises a set of attributes 701 A being Dicom Type, Construction, Geometry etc. Acoustic Module 701 can be of either the AcMod Single 702 type or the AcMod Array 703 type. These two types exclude one another, and they comprise their respective associated set of attributes 702A and 703A, respectively. The attribute set 702A associated with the component AcMod Single 702 includes inter alia the attributes NumberCodeChannels, NumberCodePulserJump, RotationDirection, StartingAngle etc. , whereas the attribute set 703 A associated with the component 703 inter alia includes the attributes NumberElements, BlankingDistance etc.

The Acoustic Module 701 is associated with a Transducer with the serial number 704. A plurality of Acoustic Modules 701 can apply to a Transducer with the serial number 704, and a predetermined Transducer with the serial number (specified) 704 can include more than one Acoustic Module 701. A Transducer with the serial number 704 includes exactly a Type 706, which further can include one or more PunctureGuides 707 associated with a set of PunctureLines 708. The PunctureLines 708 represent in connection with the component AcMod Position 710 a definition of a set of guide lines which can be displayed on the screen of the console of the ultrasonic system, and the Type 706 is associated with a Slot 709 representing a hole in a predetermined transducer type which is able to include an arbitrary number of Slots 709, whereas one Slot can only include a single Type 706.

The Acoustic Module 701 includes furthermore an Impedance AdaptionLayer 713, a set of AcMod Console Depending Data 712 and a 2400 Console Configuration 711.

The interrelation between the individual components shown in Fig. 7 allows both a high flexibility for the system according to the invention and an unambiguousness in the determining of the individual parameters for a predetermined ultrasonic transducer. Several instances of some components can exist in a predetermined context, whereas other components are only related to a single instance in response to the nature of the remaining components.

When the system is to be extended, two possibilities exist.

1. The format of an already defined data set can be extended by appending more fields to the definition of the format. To be backward compatible, the meaning of the data already defined must not be changed and it must be possible to obtain access the previously defined data without any knowledge of the added data. For databases this requirement is straight forward. Adding new columns does not effect the existing columns. For the said PROM 2 the latter means that it must be possible to detect and skip added data.

2. New data set formats can be defined. Such an extension of the system is backward compatible and allows an implementing of new formats.

Appending new data to a data set opens for a third type of version, viz. the version of the data set format. In PROM 2 the latter corresponds to an extension of the version for the blocks in which the data set are held. In the databases these information are not explicitly necessary.

Interface: console versus database/PROM.

As the console specific database 7 must be able to coexist with PROM 2, specific contents version fields must be adhered to each data set in order to allow a selection between transducer data from the console specific database 7 and PROM 2. As mentioned before, the contents version is divided into two fields where the CMNers corresponds to the major change of the contents and CMiNers corresponds to minor changes of the contents, i.e. changes without any significant influence. Based on these fields the console 1 selects the newest data of relevance to support a predeter- mined transducer knowing its own hardware and software versions, the transducer model and the associated acoustic modules.

In connection with an optimizing of the console 1 , it is furthermore desired to be able to transfer data from said console 1 to the mother database 4.

The interface between the console 1 and the console specific database 7 highly de- pends on the console model. For the console models 2101 and 2102 the interface between the console 1 and the mother database 4 is formed by a file including relevant data from the child database 7.

Console PROM

The contents of PROM 2 are read as a stream of databytes and interpreted.

Redundant data in PROM and in the database 7 must have the same format in such a manner that the transducer data either from PROM 2 or from the console 1 can be utilized by the console 1.

Interface: console versus database/PROM.

The console software must ensure the following:

Only blocks where the CRC check sum is valid must be usable.

All extensions necessary for the console are known (implemented).

The console must be able to retrieve the newest available, sufficient and agreeing data concerning the transducer 12 either from the child database 7, PROM or a combination thereof.

The latter is allowed in the following manner:

Read and validate the contents of PROM.

See the flow chart "validate and choose block" of Fig. 4. Choose between transducer data from the child database 7 or PROM 2.

Choose the newest data providing a complete data set. The newest data are selected by means of the contents version of the block.

Check whether the data are sufficient for supporting acoustic modules of the trans- ducer 12.

The contents version is divided into two fields. A CMNers reflecting major changes of the contents and a CMiNers reflecting minor changes of the contents. Minor changes are changes not influencing the compatibility with previous versions.

The flow chart "Decide transducer support" of Fig. 4 shows that for supporting a transducer 12 the relevant contents of PROM 2 must be valid, and the acoustic module and module specifications and system data must be available. The system data must be based on specifications compatible with the available specifications.

The flow chart "Validate and choose block" of Fig. 5 shows that the validation includes two parts. The CRC check sum is calculated in order to validate the contents of the block and controls as well that all the necessary extensions have been implemented.

It should be noted that some consoles do not fully exploit the utilization of the PROM contents and therefore need not know the contents version. The console types 2101 and 2102 are examples thereof, whereas the console type 2400 is able to utilize the entire contents of PROM.

The interface between console and mother database.

The child databases 7 form the interface between the mother database 4 and the consoles, but several intermediary steps can apply before the data are stored in said console 1.

The format of the child database 7 depends on the type of console. The child database 7 is an extract of the data relevant for the particular console model in a format suited for implementation in the console 1.

For a console of the type 2400 it is a database in the console 1 , and the interface is formed by a DAO (Data Access Object). DAO derives all relevant data for the specific transducer associated with the transducer placing these data in the memory of the console 1. Transfers of data from the database to the console 1 are carried out by means of methods provided by using DAO on 2400 MS Access database.

The interface between console and PROM 2.

The contents of PROM 2 are read as a stream of bytes and interpreted.

The data in PROM 2 are arranged in blocks. Each block has a starting signal identifying the type and the layout format of the block, and a CRC 16 check sum ensuring that the data are valid. When the check sum indicates an error, the console 1 rejects the block which in turn implies that the console 1 cannot use the transducer 12.

When a console discovers a block relevant to the console 1 , and the block is marked as being necessary for a level where the console 1 does not support, the console 1 cannot use the transducer 12 or the acoustic module.

The programming of the system is obvious to a person skilled in the art and can for instance be carried out in the programming languages C^{+ +} , Java or Delphi.

Claims

1. System for handling operating parameters for a diagnostic ultrasonic system comprising an ultrasonic transducer (12) emitting acoustic signals to the surroundings and receiving return signals from said surroundings, as well as an associated console (1), said ultrasonic system comprising a set of operating parameters, characterised in that data concerning the operating parameters are placed at the transducer (12) and can be transferred to the console (1), said operating parameters for instance including the module type of the transducer, the parameter values, the calibration data etc.

2. System as claimed in claim 1, characterised in that the data placed at the transducer (12) are entered a PROM (2) communicating with a plug-in member at the end of the connector for the transducer (12).

3. System as claimed in claim 2, characterised in that the data in said PROM (2) communicate with a transducer test system (3), which in turn communi- cates with a database (4).

4. System as claimed in one or more of the preceding claims, where a first part of the operating parameters are placed at the transducer (12) and another part of said operating parameters are collected from the console (1).