Cutting Edge Issues
Internet-Enhanced Physician Practices

Deploying a PACS: Issues to consider

Application Service Provider PACS: Analyzing Costs of Service

eHealth:
Towards A New World of Communications in Medicine

Case Study Zone
St Paul Radiology Goes Filmless

Who is eMed?
Mission Statement
Customer Base
Partnerships
Product Offerings
Support Services

Application Service Provider PACS: Analyzing Costs of Service

Part 3

For the present, ASP programs for PACS can be both attractive and confusing. Depending on the company involved, one might hear claims that the ASP plan:

• saves money,
• removes a heavy burden from the institution's information-services staff,
• is a great way to get started in PACS use, and
• does not tie the organization to expensive hardware and software that will only become obsolete.

Some of the product descriptions, in fact, make the ASP sound like the remotely hosted PACS of the future. Even the best programs cannot go that far. Their remote servers cannot deliver all the expected features of a PACS over a wide-area network (WAN) to simple display stations. Today’s ASP programs still require an impressive list of conventional PACS components located in the imaging department. Only a few of the PACS applications can be provided from a remote site.

Exactly how much can today’s ASP programs deliver (including remote and thin-client services), and how can the value of these programs be judged? The easiest way to determine the answer is to build a traditional PACS on paper and see how much of that system can then be replaced by the ASP program. This exercise should clarify the nature of the services being provided, as well as the relative advantages and disadvantages (business worthiness) of the ASP program. Any imaging department administrator should be able to perform this exercise, as the necessary information is not difficult to obtain. The model that follows, based on real data provided by an imaging department performing 100,000 procedures per year, will serve as an example.

Designing a PACS on paper is a reasonably straightforward task. Basic information about a film-based operation, such as that presented in Table 1, can be used to create a reasonably accurate component list for a PACS. In the real world, the opinions and experience of the professional staff (both inside and outside the imaging department) and a complete need assessment would be used to fine-tune the configuration.

The PACS model can be divided into six major subsystems. The first, the acquisition subsystem, includes all the necessary interfaces required to capture image data throughout the imaging department. It includes Digital Imaging and Communications in Medicine (DICOM) software, external frame grabbers, computed radiography, and digital radiography.