An Architectural Route through PACS

Digital archiving of diagnostic images has been in demand for many years-particularly since optical mass storage technology increased the chances of its realization. Technically, the digital picture archive was regarded as a giant data store with film input and hardcopy or soft-copy output-a simple and straightforward concept. Then, as more and more digital imaging machines were implemented in hospitals, mass storage media for archiving the digital pictures were looked upon as peripheral devices to the picture-generating machines. Meanwhile, it was becoming obvious that digital picture archives would be far more than isolated devices or extensions to existing isolated devices. Instead, they would become the kernel of networks that would connect a variety of imaging machines, interact with hospital databases and administration systems, and, last but not least, facilitate communication of pictorial and other information between medical personnel. This perspective added tremendous complexity to the concept. Complexity is mainly a consequence of looking at PACS from the standpoint of the user, the network engineer, the designer of imaging (sub)systems, or the manufacturer of high-technology key components. For instance, the user's demands conflict with the manufac-turer's product strategy. The user needs a system that is highly adaptable in terms of functions and structure to his individual work situation. The manufacturer, however, for the sake of economy, must produce standard products with a fixed catalog of functions. Another complication is that some well-established, basic data processing concepts have to be thrown overboard when innovative technologies, techniques, and methods are employed to process, store, and communicate a large number of high-resolution pictures with sufficient speed. Hasty development with inadequate concepts can result in the proliferation of confusing and redundant systems. A thorough architectural approach is urgently required to decorrelate user requirements from technical and manufacturing boundary conditions and produce generic concepts for system modules and procedures down to the bottom system level. This article presents a general procedure for an adequate architectural approach and describes in detail concepts for solving the basic technical problems. A conceptual process must be top down, but where is the top and where is the bottom? The structure of a process depends on the observer's perspective. A PACS is a typical example of a system with multiple dimensions, including user, network, system management, data processing , and other dimensions. The system architect's primary mission is to define the system's dimensions such that conceptual models from the different perspectives become …