Surgery – Diagnostic testing – Detecting nuclear – electromagnetic – or ultrasonic radiation
Reexamination Certificate
2003-03-20
2004-05-11
Jaworski, Francis J. (Department: 3737)
Surgery
Diagnostic testing
Detecting nuclear, electromagnetic, or ultrasonic radiation
Reexamination Certificate
active
06733449
ABSTRACT:
BACKGROUND
Diagnostic medical ultrasound systems are routinely used in medical applications for the purpose of imaging various body tissues and organs and for other diagnostic and therapeutic purposes. These systems allow medical professionals to view the internal conditions of a patient thereby enabling them to render a better diagnosis. In one example of a diagnostic medical ultrasound system, a piezoelectric transducer acquires image data by transmitting a series of ultrasonic pulses into a patient and receiving the echoes therefrom. These echoes are converted/manipulated into an image and displayed on a monitor or stored for later use. This process can be further characterized as a continuous or streamed process. As the echoes are received by the transducer, they are converted and displayed in a continuous fashion, i.e., streamed from the transducer to the display.
The ultrasound system is primarily designed to process the received echoes in this streaming fashion. To improve the functionality of the ultrasound system, applications may be provided which post-process the received echoes to enhance the usability of the data. For example, color coding may be added to further enhance the visibility of Doppler shifts in the echoes. Any post processing of the received echo information must either operate in a streamed fashion, i.e. operate on the received echo data as it is received in real time, or buffer/store a portion of the received echo data and operate on that buffered/stored portion.
Development of applications which can operate in real time on the received echo information is complex and resource intensive, such that the number of such streaming applications offered on a given ultrasound system is often limited. Furthermore, many of today's applications rely heavily on expensive custom hardware components specifically designed to perform data processing, such as a 3D imaging calculator. Use of these hardware components limits the reusability and flexibility of the application and the ultrasound system. The hardware components also typically tie up any ultrasound data being processed until a final result is produced, thereby preventing multiple applications from operating in parallel. Further, these applications are typically structured based on the nature of ultrasound system itself, i.e. the application's functionality is divided among three functions: acquisition of data, manipulation of data and storage or display of the manipulated data. Typically, the application developer, in designing the software architecture of the application, makes initial assumptions about each function's role in the application. For example, the data acquisition function might assume that a certain piece of hardware in the ultrasound system was always going to be used. It may then use global data structures that are very specific to this piece of hardware. The acquisition function would then acquire data, place it into and control it with one of these global data structures. The data manipulation and storage functions would then need to access these global data structures in order to retrieve both control and ultrasound imaging data to perform their tasks. In this way, all three functions have become dependent on a specific piece of hardware. Should that hardware change, or any control information in the highly coupled data structure change, all three functions would need to be modified. Another example of functional co-dependency is a simple in-process frame grabbing application. A data source acquisition function might always assume it will acquire the same kind of data and that this data will always be compressed and stored in the same particular way. As a result, the acquisition function would be coded in a way to take advantage of these assumptions, typically for performance reasons. If either the data manipulation or data storage function changed, it would likely break the acquisition function. If a need arises to make data storage out-of process, it is likely to have significant impact on both data acquisition and manipulation because both assumed that the whole application would be handled in-process. In sum, the more assumptions made, the more dependent each function becomes on the other two and the more difficult application development and maintenance becomes.
FIG. 1A
shows one example of a monolithic ultrasound streaming application. As known in the art, a monolithic program is a program with very few classes or structures. These classes or functions exhibit a high degree of physical and data coupling between one another. In such an application, each of the three functions, i.e. acquisition
2
a
, manipulation
4
a
and storage
6
a
, is coupled to each of the other two because many initial assumptions are made. For example, data acquisition
2
a
is dependent on both data manipulation
4
a
and data storage
6
a
. When a change is made to any of the functions, each of the other two functions must be corrected accordingly. Thus, all of the functions must be recompiled and tested when a change is made to any function. Furthermore, each function does not have clear responsibilities. Each function may be responsible for more or less than its name implies. It is typically more cost-effective to write an entirely new application instead of fixing problems with a monolithic ultrasound streaming application because of the problems associated with coupling and the lack of clear responsibilities. Finally, the functions of a monolithic ultrasound streaming application are not reusable because so many assumptions are made and the individual processing steps are buried in the bulky mass of programming code.
FIG. 1B
shows an example of a modular ultrasound streaming application. In a modular ultrasound streaming application, modules have been created that clearly define the responsibilities of each function. Each function also has a well defined Application Programming Interface, or API. Here, the dependencies of each function have been reduced. However, acquisition
2
b
is still dependent on manipulation
4
b
, which is still dependant on storage
6
b
. In this scenario, an alteration in the data storage
6
b
function will still require the manipulation
4
b
and acquisition
2
b
functions to be recompiled, re-linked and retested. Although alterations to a modular ultrasound streaming application are less expensive than in monolithic ultrasound streaming applications, alterations can still be costly. Furthermore, modular applications are not easily reusable as the various functions are still buried in large amount of programming code.
While such applications provide a valuable diagnostic tool to physicians, they also suffer from inherent limitations and may make real-time data processing at minimum difficult, if not impossible, to complete without extensive testing and cost. Furthermore, these applications are not designed to be reusable and do not allow access to intermediate data.
Accordingly, there is a need for a flexible, reusable, low cost ultrasound streaming application architecture that reduces dependency on custom hardware components and legacy programs while making ultrasound data readily available at any point throughout the course of processing. Further, there is a need for an ultrasound streaming application architecture that further reduces the number of initial programming assumptions made in development, thereby reducing dependencies between the underlying functions of the application.
SUMMARY
The present invention is defined by the following claims, and nothing in this section should be taken as-a limitation on those claims. By way of introduction, the preferred embodiments described below relate to an ultrasound stream manager for a diagnostic medical ultrasound system, the ultrasound system comprising at least one processor, at least one data source and at least one data sink. The stream manager is operative to facilitate communication between a first application program executing in the processor and at least one of the at least one data source and
Krishnamurthy Suresh B.
Landry Peter B.
Marney Christian H.
Nadadur Desikachari
Waataja David A.
Jaworski Francis J.
Siemens Medical Solutions USA , Inc.
LandOfFree
System and method for real-time streaming of ultrasound data... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for real-time streaming of ultrasound data..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for real-time streaming of ultrasound data... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3188550