Most commercially available Picture Archive and Communication Systems (PACS) follow the following popular architectural layout:

• Input modalities. These are the CT, MRI, CR, Ultrasound, and Nuclear Medicine systems or imaging devices where the C-STORE requests are coming from.
• DICOM server. This is mostly a program that runs as a background process and waits for the input modalities to send it DICOM formatted images using the DICOM 3.0 protocol. This system can also manage requests from workstations and other PACS.
• PACS server. This program contains a database that keeps track of every image in the PACS. It is also a file server to hold the received images, depending on the size of the disk file system and how many images that you desire to be online. There may be more than one file servers.
• Archive server. The archive server stores the images onto a long-term storage media other than the hard disk, such as MOD, DLT, DVD, etc. There may be a separate database that keeps track of what tape or MOD an image is archived on.
• Web server. The web server is a more cost effective way of distributing images to clinicians, rather than having to buy a radiology workstation at $70,000 to $100,000 a system. This can be either commercial HTTP servers (like Microsoft IIS) or public domain HTTP servers (like Apache).
• RIS (Radiology Information Server) interface computer. This is the interface between the RIS and the PACS database using HL7 to communicate between the two computer systems. It can also provides DICOM patient information to the imaging modalities.
• Radiology clients. The radiology clients are usually high powered systems that display and manipulate the images for the radiologists.

The above PACS server design may have the following implementation issues:

• Cost. If each of the above PACS server component consists of a separate computer system, the capital expenditure requirements to implement the PACS server design would be so high that few users could afford such a PACS server implementation.
• Complexity. Again, if each of the above PACS server component consists of a separate computer system, it would make maintaining the PACS server network a challenging task and the operational expenditure requirements could grow out of control.
• Integration with the rest of IT infrastructure. The more computer systems are involved in implementing the PACS server, the more potential problems that the PACS administrators may run into since there are more network administrations, more user account administrations, more security administrations, as well as more check-points when trouble-shooting problems.

That is why you may want to consider PacsOne Server (PACS Server In One Box), which provides Solutions for the implementation issues described above.