A Generic Hospital PACS RFP

presented to

The Seventh RIS-PACS School

Georgetown University Medical Center

by

John H. Perry

Version: 1

Revision Date: 7/9/97

- 11 -

Preface..................................................................................................4

1 Project Overview...............................................................................41.1 Summary..................................................................................41.2 Clinical Operations..................................................................51.3 Specification Format................................................................71.4 Revision History.......................................................................7

2 System Components..........................................................................72.1 System.....................................................................................72.2 Network...................................................................................82.3 Database..................................................................................92.4 Storage System......................................................................112.5 Archive System......................................................................122.6 External Information System Interfaces................................142.7 Image Acquisition Systems....................................................15

2.7.1 DICOM.........................................................................152.7.2 General Modalities......................................................16

- 22 -

2.7.3 Computed Radiography (CR).......................................162.7.4 Film Digitizer (FD).......................................................172.7.5 Modality Clusters.........................................................18

2.8 Image Display Workstations..................................................182.8.1 Configuration...............................................................192.8.2 Monitors......................................................................192.8.3 Monitor Calibration.....................................................202.8.4 Performance................................................................202.8.5 User Interface..............................................................202.8.6 Exams, Folders, Worklists, and Queries.......................212.8.7 Reports........................................................................222.8.8 Exam Display and Arrangement..................................222.8.9 Image Display and Paging...........................................232.8.10 Grayscale Operations.................................................242.8.11 Image Orientation, Zoom, Pan, and Magnifying Glass

....................................................................................252.8.12 Region of Interest, Distance, and Angle Measurements

....................................................................................262.8.13 Image Annotation......................................................262.8.14 Image Identification...................................................262.8.15 Utility Functions........................................................272.8.16 Control of Hard Copy Printing...................................27

2.9 Film Printers..........................................................................28

- 33 -

2.10 Web Servers and Web Workstations....................................29

3 System Integration..........................................................................303.1 Operations.............................................................................303.2 Reliability...............................................................................30

4 Purchased Components...................................................................314.1 Configuration.........................................................................314.2 Startup Kits and Supplies......................................................31

5 Installation.......................................................................................315.1 Hospital-Furnished Equipment and Services.........................315.2 Supplier-Furnished Equipment and Services........................325.3 Environmental Requirements................................................325.4 Installation Facilities..............................................................33

6 System Acceptance..........................................................................33

7 Training...........................................................................................34

8 System Warranty and Maintenance.................................................348.1 Warranty ...............................................................................348.2 Maintenance .........................................................................358.3 Spare Parts............................................................................36

9 Contract Administration..................................................................36

10 Proposal Structure.........................................................................36

- 44 -

Preface

This paper is a companion document to “A PACS RFP Toolkit,” a paper which has been presented at each of the last three RIS-PACS Schools in continually updated form. The toolkit addresses the key issues in specifying a PACS, but it does not contain an example of a complete specification. The purpose of this paper is to provide a concrete example which may help in some PACS procurements.

This document is primarily a technical requirements specification. The system specified is a generic, full-hospital PACS without teleradiology. No requirements are included for allowing input or modification of reports at PACS workstations. Additionally, no requirements are included for the purchase of CR units. Finally, since each institution has its own purchasing process, no attempt has been made to specify contract terms and conditions.

This specification has been assembled from several of the last few years’ PACS RFPs and RFIs, along with contents from the toolkit, edited into a consistent document. Comments as well as notes on errors and omissions will be gratefully received at “jperry@interaccess.com”.

1 Project Overview

This document solicits proposals from qualified vendors to provide a Picture Archiving and Communication System supporting a fully digital radiology department, image distribution services to all departments in the hospital, and interoperation with other hospital information systems.

1.1 Summary

The hospital is a private 500 bed medical center consisting of five patient care facilities and several office buildings.

During the last fiscal year, the hospital experienced 25,000 inpatient admissions, 200,000 outpatient registrations, 50,000 emergency room visits, and 5,000 observation registrations.

The radiology department is decentralized, with imaging rooms, interpretation rooms, and film libraries throughout the campus.

The radiology department performs approximately 200,000 studies per year, broken down as shown in the procedure volume analysis in Appendix I.

The radiology department has begun to convert to filmless technology and the hospital is committed to extend that effort throughout the

institution. To support that commitment, the hospital seeks a qualified system integrator to implement a full-hospital digital image management system to improve access to patient information, reduce operating costs, and promote the hospital’s competitive position.

The key initial objectives are:

• Reduction in uninterpreted/unreported cases resulting from loss or confiscation of images, particularly related to critical care and emergency department imaging.

• Reduction in production of duplicate copies of analog images particularly for critical care and emergency department images.

• Reduction in human resource consumption through a decrease in rework and an improvement in operational efficiency, especially in general radiology.

The hospital is prepared to accept either a single phase or multi-phase approach to achieving its goal. In either case, the hospital expects the proposed project to provide a substantial core of filmless operation within one year of the contract award.

1.2 Clinical Operations

This section is not normative. It provides examples of the clinical operation of the system as envisioned by the hospital to aid in understanding the desired functionality.

• Patient Registration and Exam Requisition: With the exception of certain emergency situations, all patients will be registered in the HIS/RIS, and all radiographic exams will be ordered through the RIS. The RIS will automatically inform the PACS of the scheduled exam and the patient’s demographic data.

In emergency situations where time or other constraints do not allow normal registration and scheduling procedures to be followed, the PACS will accept exams directly without orders and allow the exam data to be rationalized with RIS data when it is available.

• CR Exams: The existing CR devices in the hospital will be interfaced to the PACS in such a way that the PACS can provide worklists of ordered CR exams from which the technologist may select the current exam and receive the patient demographic data without further data entry. Initial QC will be performed by the technologist using the video display connected to the CR plate reader. Final QC for CR exams will be performed by designated technologists at PACS workstations. CR exams which have not been approved by the QC procedure will be accessible only to authorized users.

• CT & MR Exams: The PACS will provide modality worklists to the CT and MR systems, allowing those modalities which support worklists to acquire patient demographic data without technologist input. Exams will be completely acquired at the modality before transmission to the PACS. QC will be performed at the modality. Exams received at the PACS will require no further interaction to be made accessible to users at PACS workstations.

• Special Procedures: Special procedures exams will be acquired like CT and MR exams, except that in some cases (e.g., DSA) only a small subset of the images, selected at the modality, will be transmitted to the PACS.

• Modality Clusters: Nuclear Medicine and Ultrasound modality clusters will operate independently of the PACS and transmit their exams to the PACS after their internal QC procedures are complete.

• Stat Exams: Exams designated as stat in the exam order entry process will be identified in the PACS, and the PACS will provide workstation users with lists of stat exams for rapid access.

• Film File Room Operations: Selected exams on film will be entered into the PACS at the film digitizer in the film file room. It will be possible to enter the exam modality, scheduling infomation, and patient demographics at the film digitizer or, if the digitization was ordered through the RIS, to receive it directly from a film digitizer worklist. Exams acquired at the film digitizer will not require further QC to be made accessible.

• Film Printing: PACS film printers will be accessible only to authorized users. The films will automatically be printed with the requesting user’s name.

Exams for use in OR will be manually selected and printed on film.

• Diagnostic Reporting: Authorized users will access worklists of unread exams for dictation. Relevant historical exams, along with their reports, will be available for simultaneous display at the time of diagnosis, having been previously dearchived by an automatic prefetching process. Users will generally monitor worklists based on modalities, however, it will also be possible to find specific patients by name or ID. During a diagnostic session, a user will be able to select a specific case from the list or automatically move sequentially down the list. In the latter case, after completing the dictation (to a separate dictation system), the PACS will automatically change the status of the current exam to indicate that it has been read, close the exam,

and open the next one in the worklist. When displaying an exam or a set of related exams for a diagnostic session, the system will automatically present the images in a reasonable arrangement to speed the process. Window width and level and image rearrangement will be used frequently. Following transcription, the dictated report will be transmitted from the RIS to the PACS to make it accessible for display at the workstations. Subsequent changes to the contents or status of the report will also be sent to the PACS. Report approval will be possible on the PACS workstation, in which case the status change will be sent to the RIS.

• Clinical Exam Review: Authorized users will submit queries to the system database by choosing one of a selection of predefined worklists or views, thereby accessing lists of exams, folders, and patients. Reports for exams will be visible on the workstation. Exams will be selected and displayed in the format in which they were last saved. Window width and level and image rearrangement will be used frequently.

• Archived Exam Retrieval: Lists of exams displayed at workstations will indicate whether the exams are online or in the archive. Authorized users will have access to exams in the archive through a fetch process. Fetch requests will be serviced in an order consistent with their individual priorities.

1.3 Specification Format

The specification contained in this document is structured as a series of normative statements. Each normative statement is a requirement which must be met by the vendor’s proposed system. The specification language obeys the following conventions:

1. Paragraphs containing normative requirements shall be individually numbered.

2. A paragraph shall contain at most one normative statement.

3. A normative statement shall define one requirement.

4. A normative statement shall contain the word "shall".

5. A paragraph shall contain as much clarifying language as desired.

6. Clarifying language shall not be considered normative.

Note that Section 10 requires that any exceptions to the normative requirements be documented in the proposal.

1.4 Revision History

Rev Date Description

1 7/9/97 First draft for the Seventh RIS-PACS School

2 System Components

2.1 System

2.1.1 The proposal shall include a detailed description of the architecture of the system, documenting the system topology and the components of the system.

2.1.2 The proposal shall include a description of the theory of operation of the system, including the data flows for:

• image acquisition from CR• image acquisition from a DICOM modality• communication with the external RIS• database access by a workstation• exam selection and image display• archiving• ad hoc dearchiving

2.1.3 The proposal shall clearly state whether the system relies on the routing of images to fulfill performance requirements, and if so, the routing model shall be documented.

2.1.4 If the system relies on auto-routing, then it shall be based on a configurable algorithm which constitutes combining a set of selection criteria according to a set of rules.

2.1.5 Known upper limits of the architecture with respect to storage capacity, processing capacity, network throughput, input/output throughput, etc., shall be individually documented in the proposal, along with the capacities of systems currently in clinical operation.

2.1.6 The system shall meet all performance requirements in this specification with the database storing five years’ examinations, the storage system filled to its normal steady-state maximum, under an image request load of the daily image production as defined in Appendix I, multiplied by 27 accesses per image, delivered over a five-hour period.

2.1.7 The system shall support system-wide authentication of users through the use of a unique user-ID and password for each user or through an alternative approach with equivalent result.

2.1.8 The system shall present a unified view of all exams across all connected hospital domains. This requirement is not to be interpreted to require any specific physical architecture; it only requires that the user be able to find and access any exam known to the system without knowing its location. This requirement is also not to be interpreted as disallowing location-specific views in addition to the unified view.

2.1.9 It shall be possible to use the PACS to acquire and view demographic data and exams on patients, including those not already known to the system, when the RIS or the RIS-PACS interface is unavailable.

2.1.10 The vendor shall provide mechanisms to assure the security of all system components to minimize loss of equipment or data due to theft or malicious tampering.

2.2 Network

The assumption is made that the communication system of the PACS will include a local area network which will be implemented as a set of connected hubs. The vendor will provide all the required network infrastructure to implement the requirements of this RFP for the diagnostic and review workstations and for those web workstations which are within the area served by one of the LAN hubs. For the purpose of sizing the hubs, the vendor is to assume that any hub will support as many web workstations as diagnostic and review workstations.

The hospital has a corporate communications network which is described in Appendix VI. The corporate network will be used to support expansion of the web-based service to users not serviced by the network infrastructure required by this RFP. To support that objective, the vendor’s network which supports web workstations will be bridged to the corporate network.

2.2.1 Monitoring and management of the network and its components shall be possible from a system management application which shall provide comprehensive functionality for monitoring traffic patterns, loss of packets/cells, network component failures, re-configuration, etc. A system management

facility based on the Simple Network Management Protocol (SNMP) protocol is preferred.

2.2.2 The system network shall include a bridge to the hospital’s corporate network as required to allow the corporate network to be used to support web-based access.

2.2.3 The system network shall include a bridge to the RIS network.

2.2.4 The system network shall isolate its internal traffic from all other networks to which it is connected.

2.3 Database

2.3.1 The system shall support the association of individual users to one or more user-groups each having individually configurable access-privileges.

2.3.2 The system shall provide an access control mechanism that enables assignment of unique access privileges to individual users and user groups to access or alter system resources and data. Examples of such functions are:

• Displaying approved reports• Displaying unapproved (unsigned) reports• Displaying images• Printing images• Ad hoc queries of the system database (worklists,

etc.)• Dearchiving exams• Quality control of exams• Changing the status of images and exams• Changing the display attributes of exams• Approving reports• Creating, modifying, or deleting academic and

private folders

2.3.3 The system shall model all events, statuses, and status changes necessary for proper synchronisation with the RIS and to support system-wide worklists.

2.3.4 The system database shall have a capacity to store seven years of exam information based on the annual procedure volume specified in Appendix I, plus 50%. This requirement is not to be interpreted to imply that images are to be stored in the database, only that the

information which is required to be accessed in searching the database for an exam is to be stored for seven years in the database.

2.3.5 The amount of storage proposed in fulfilment of 2.3.4, and the basis for its calculation, shall be documented in the proposal.

2.3.6 A mechanism shall be provided to permit a system administrator to age patient records out of the database (for example, to remove records after seven years or after the age of majority of the patient).

2.3.7 The database shall enable workstation users to submit queries to the database to obtain a list of references (worklists and folders) representing a subset of the exams in the database.

2.3.8 The database shall support ad hoc queries using search criteria based on the values, or range of values, of the data items of the table below, combined using logical operators (e.g. “AND”, “OR”, “NOT”) and with the ability to sort results in ascending or descending order. Functionality equivalent to an SQL Select statement is intended. The purpose of this requirement is to assure that worklist queries and administrative report queries can be constructed to support a range of needs. This requirement is not to be interpreted to require that all users be able to initiate queries using SQL directly.

DICOM Attribute

Name

(Searchable Item)

DICOM Tag

Patient’s Name

(0010, 0010)

Patient ID (0010,0020)Accession Number

(0008,0050)

Requesting Service

(0032, 1033)

Requested Procedure Code Sequence

(0032, 1064)

Study (0008,0030

Time

Study Date

(0008,0020)

Study ID (0020,0010)

Study Description

(0008,1030)

Study Status ID

(0032,000A)

Study Priority ID

(0032,000C)

Interpretation Status ID

(4008, 0212)

Modality (0008, 0060)

Body Part (0018, 0015)

Interpretation Diagnosis Code Sequence

(4008, 0117)

Institutional Department Name

(0008,1040)

Patient’s Institution Residence

(0038,0400)

2.3.9 The database shall be backed up and verified by an automated procedure that does not take the database out of service or significantly impact database performance.

2.3.10 A system-wide administration function shall be provided to facilitate user and group profile creation (as required in 2.1.6 and 2.3.2), worklist query creation (as required in 2.3.7 and 2.3.8), system configuration management, data integrity checks and maintenance, and any other administration functions as required by the implementation of the product. A graphical user interface for this function is strongly preferred.

2.4 Storage System

In this document, the term “storage system” refers to on-line storage for rapid access to images. The assumption is made that in order to

meet the performance requirements of the system, the storage system will be separate from the archive system and employ different technology, but none of the requirements in this RFP are to be interpreted to force that architectural implementation.

2.4.1 The system shall provide sufficient storage capacity to provide access to 30 days of image production, as defined in Appendix I, plus two dearchived exams for each newly acquired exam.

2.4.2 The basic element of storage and retrieval for the storage system shall be the exam.

2.4.3 The system shall not store any image in the storage system with non-reversible compression before the diagnosis of the exam of which the image is a part is complete.

2.4.4 The system shall make exams available for retrieval by workstations within one minute of their receipt in the storage system.

2.4.5 The system shall not automatically delete from the storage system any exam until space for new exams is required. "Is required" can be interpreted to mean "is expected to be required in the near future".

2.4.6 The system shall select exams for automatic deletion from the storage system in order of priority as follows:

1. dearchived exams not associated with other exams

2. dearchived exams associated with exams for which the primary diagnosis is complete

3. archived exams for which the primary diagnosis is complete

4. dearchived exams associated with exams for which the primary diagnosis is not complete

5. archived exams for which the primary diagnosis is not complete

6. exams which have not been archived.

2.4.7 The policy for automatic deletion of exams from the storage system, as specified in 2.4.6, shall be reconfigurable by the system administrator.

2.4.8 The storage system shall monitor usage and provide real-time display of usage patterns and statistics.

2.4.9 The storage system shall tolerate the failure of a single disk drive without loss of data.

2.4.10 The storage system shall remain operational in the event of the failure of a single disk drive.

2.4.11 A description of the consequences of a disk failure (both transient at the onset of a failure, and any effects lasting until the failure has been corrected) on the operation, performance, or vital functions of the storage system shall be documented in the proposal.

2.4.12 The storage system shall remain operational during the service required to correct a failed disk drive.

2.4.13 The storage system shall provide means for notifying the system administrator in the event of a failure in the storage system. The use of SNMP for this function is preferred but not required.

2.5 Archive System

In this document, the term “archive” refers to storage for long-term access to images.

2.5.1 The system shall include sufficient on-line archival storage to provide access to at least two years' image production, as defined in Appendix I, without intervention by a human operator. For the purpose of estimating the required archival storage required, CR is assumed to be archived using the algorithm of 2.5.15 with the parameters of 2.5.16 set as proposed by the vendor to provide clinically acceptable archival image quality. If the vendor’s proposed setting of the parameters of 2.5.16 yields compression greater than 10:1 for CR images, then only 10:1 is to be used for estimating the archival storage required for CR. All other modalities are assumed to be archived with the compression algorithm of 2.5.14.

2.5.2 The amount of storage proposed in fulfilment of 2.5.1, and the basis for its calculation, shall be documented in the proposal.

2.5.3 Exams older than the limit in 2.5.1 shall be accessible. Accessibility can be satisfied by requiring a human operator to insert storage media into the system.

2.5.4 If a human operator is required to intervene as in 2.5.3, the archive system shall automatically provide instructions, identifying the location of the media involved and the action to be performed.

2.5.5 The archive system shall automatically archive exams when they are received into the storage system. This requirement can be interpreted to mean that an exam is entered into a queue for archiving as soon as all the images for the exam have been received and, if required by the implementation, the exam has been verified, provided that in normal operation, the queue is always actively being served.

2.5.6 In response to the ordering of a new exam, the archive system shall automatically dearchive related exams according to a prefetching algorithm.

2.5.7 The vendor shall include in the proposal a detailed description of the prefetching algorithm, including those parts, if any, which are configurable by the system administrator.

2.5.8 The archive system shall dearchive exams in response to ad hoc requests from users at workstations.

2.5.9 The archive system shall support priority queuing of dearchival requests.

2.5.10 The dearchival priority scheme of 2.5.9 shall be configurable by the system administrator.

2.5.11 The archive system shall monitor usage and provide real-time display of usage patterns and statistics.

2.5.12 The archive system shall dearchive a standard exam within 60 seconds. Dearchival time is measured from the time the archive system begins servicing a dearchive request for an exam which is located in the on-line archive until the exam is completely stored in the storage system, including any mechanical seek time required by the implementation. A standard exam is any one of the following:

• two images of 2K x 2.5K x 2bytes• 20 images of 512 x 512 x 2bytes• 80 images of 256 x 256 x 2bytes

The images are to have been stored with whatever compression is proposed for the system.

2.5.13 The archive system shall be able to service an archive/dearchive request load defined by the daily image production as defined in Appendix I, multiplied by 6, within a 16-hour period.

2.5.14 The system shall provide a reversible compression algorithm for use during archiving.

2.5.15 The system shall provide a non-reversible compression algorithm for use during archiving.

2.5.16 The non-reversible compression algorithm shall have one or more configurable parameters which affect the degree of compression.

2.5.17 The proposal shall include a mathematical description of the non-reversible algorithm.

2.5.18 The system shall allow the user to designate, for each modality, the compression algorithm and any configurable parameters to be used in archiving exams for that modality.

2.5.19 Any negative consequences for compliance with the requirement for the DICOM Storage SCP and Query/Retrieve SCP, described elsewhere in this document, by using the algorithms in 2.5.14 and 2.5.15 shall be described in the proposal.

2.5.20 The archive system shall store exams for seven years without loss of data. This requirement is not intended to imply "with reversible compression," only that the exams, in whatever form they are archived, remain accessible for seven years.

2.5.21 The supplier shall include with the proposal the results of studies demonstrating the stability of the archival storage media and descriptions of any procedures required to assure that 2.5.19 is met.

2.5.22 The supplier shall guarantee that the archive system will be supported with media, spare parts, and service for at least ten years from the acceptance date.

2.6 External Information System Interfaces

The hospital uses the <RIS name> RIS. The RIS will remain the primary site of data entry. In the PACS environment, the RIS is expected to notify external applications when changes occur to certain identified types of information. This model is consistent with both the DICOM and HL7 standards. The RIS and PACS will exchange information about scheduled procedures, patient demographics, and final reports. The two systems will also perform mutual data integrity functions such as patient and exam merge, exam cancellation, and status tracking and synchronization.

2.6.1 The vendor shall co-operate with the hospital and the RIS vendor to define a fully functional, bi-directional interface between the system and the RIS based on either the DICOM or HL7 standard. A DICOM-based interface is the preferred implementation.

2.6.2 The interface of 2.6.1 shall support:• exam order entry transfer from the RIS to the

PACS to support prefetching and transfer of patient demographic information

• bi-directional transfer of demographic and status change information

• transfer of radiographic report text from the RIS to the PACS and bi-directional transfer of status information to provide synchronization of the two systems with changes

• exam status information transfer from the PACS to the RIS to inform the RIS of the completion of an exam.

This requirement should not be interpreted to disallow bi-directional transfer of report text.

2.6.3 The proposal shall include a description of the vendor’s experience with RIS-PACS interface implementations and specifically with interfaces to the hospital’s RIS.

2.6.4 The RIS-PACS interface shall be upgraded to maintain, at a minimum, its initial functionality or extend its functionality when either the PACS or the RIS system software is upgraded. To meet this requirement, the vendor will be required to coordinate upgrade plans and schedules with the hospital and the RIS vendor, and prove through regression testing that upgrades do not have a negative impact on the interface.

2.7 Image Acquisition Systems

2.7.1 DICOM

2.7.1.1 The system shall provide a DICOM interface to which DICOM-compliant external devices may connect. External devices are devices not supplied with the system and include but are not limited to image review workstations, image printers and modalities.

2.7.1.2 The system shall include one or more DICOM Storage SCPs which support all necessary storage SOP classes

required to support the DICOM Storage SCUs implemented on the image acquisition systems listed in Appendices III and IV.

2.7.1.3 The system shall include a DICOM Query/Retrieve SCP which supports Study Root queries at the Study Level and which provides query responses for all studies, series, and images stored in either the Storage System or the Archive System.

2.7.1.4 The system shall include a DICOM Modality Worklist Management SCP (DICOM/MEDICOM Supplement 10) which provides worklists that include all studies stored in the Storage System.

2.7.1.5 The system shall include a DICOM Storage Commitment Push Model SCP which accepts storage commitment by either the Storage System or the Archive System.

2.7.1.6 The system shall include a DICOM Study Component Management SCP which correctly maps image series to RIS-ordered studies.

2.7.1.7 The vendor shall provide with the proposal one or more Conformance Statements covering all DICOM functions of the system.

2.7.1.8 The vendor shall provide upon request, conformance testing results that validate the Conformance Statements of 2.7.1.7.

2.7.2 General Modalities

2.7.2.1 The system shall support integration of the image acquisition equipment listed in Appendices III and IV. Wherever possible, the integration is to be based on the requirements of Section 2.7.1.

2.7.2.2 For each image acquisition system where integration is achieved by means other than the one described in 2.7.2.1, a thorough description of the method shall be supplied. The description shall include the method used to obtain correct patient ID and study UID and how DICOM objects such as Image Series, Study Components, and Study IODs are supported.

2.7.2.3 If integration of any of the equipment listed in Appendix IV depends on a specific level of systems software for the equipment, this information shall be supplied.

2.7.2.4 The interface between a modality and the system shall not decrease the patient throughput of the modality.

2.7.2.5 The system shall accept, store, and display the full, original image dataset transmitted from each modality.

2.7.2.6 In situations where a procedure is performed on a patient without prior registration in the RIS, no patient information and study UID is available for the modality to use for the store operation. In these cases the modality will allow the operator to enter the patient information manually, and allocate a study UID of its own. The system shall include a mechanism to remap this UID when the RIS order has been performed and communicated to the system and thereby correctly associate the acquired images with the appropriate RIS ordered exam.

2.7.3 Computed Radiography (CR)

2.7.3.1 The system shall provide a mechanism to support quality review of CR images and permit a technologist to take remedial action. Remedial actions include: image flip (top to bottom, left to right), image rotation, window width and level, image rejection (deletion from the exam) and image reprocessing.

2.7.3.2 In the event of network failure, a means shall be provided to produce hard copy output from CR.

2.7.4 Film Digitizer (FD)

2.7.4.1 The FD shall accept the following radiographic film sizes:

• 14 x 17• 14 x 14• 10 x 12• 8 x 10

or their metric equivalents.

2.7.4.2 The FD shall have a sensitive area (spot size) no larger than 175µm for each pixel.

2.7.4.3 The FD shall offer a selectable high-resolution mode with a sensitive area (spot size) no larger than 100µm for use on 8 x 10 films.

2.7.4.4 The FD shall digitize to 12 bits per pixel, with all bits being used, across a range from 0 to 3.5 OD.

2.7.4.5 The FD shall be linear within 0.02 OD across its full dynamic range.

2.7.4.6 The FD shall produce less than 0.01 OD noise at 2.5 OD.

2.7.4.7 The FD shall produce no visible noise pattern in the digitized image of a homogeneous region of a film anywhere in the density range required in 2.7.4.4.

2.7.4.8 The FD shall process one exam consisting of one film of each size required in 2.7.4.1 in less than five minutes. The time will be measured from the beginning of any required operator interaction with the digitizer (entering exam or patient information, adjusting the digitizer, inserting the films, etc.) until the last film has been digitized.

2.7.4.9 The FD shall have a film feeder capable of holding 25 films of a mixture of the sizes required in 2.7.4.1.

2.7.4.10 If an exam digitization has been pre-ordered through the PACS or the RIS, the FD shall allow the operator to acquire the exam and patient identification information necessary for digitizing one exam with a simple action. Such an action may be a keystroke, mouse click, barcode acquisition or the equivalent.

2.7.4.11 The FD shall also provide an option for the operator to enter exam and patient identification information manually for unscheduled exams.

2.7.4.12 The FD shall automatically associate the exam and patient identification information with all the acquired images for the exam.

2.7.5 Modality Clusters

Ultrasound

The general approach to ultrasound image managment will be to interface a dedicated ultrasound local area network to the system through the DICOM external device interface. Ultrasound imagers and workstations will be required to use the DICOM External Interface to access the system for any functions that require system support.

2.7.5.1 The external DICOM interface shall support storage and retrieval of ultrasound images as Ultrasound SOP Class Objects.

2.7.5.2 The system shall provide DICOM Support for ultrasound cine loops.

Nuclear Medicine

The general approach to nuclear medicine image managment will be to interface a dedicated nuclear medicine local area network to the system through the DICOM external device interface. Nuclear medicine imagers and workstations will be required to use the DICOM External Interface to access the system for any functions that require system support.

2.7.5.3 The external DICOM interface shall support storage and retrieval of nuclear medicine images as Nuclear Medicine SOP Class Objects.

2.7.5.4 The system shall provide DICOM support for nuclear medicine cine loops.

Angio

The general approach to angiographic image managment will be to interface a dedicated angiographic local area network to the system through the DICOM external device interface. Angiographic imagers and workstations will be required to use the DICOM External Interface to access the system for any functions that require system support.

2.7.5.5 The external DICOM interface shall support storage and retrieval of angiographic images as Angiographic SOP Class Objects.

2.7.5.6 The system shall provide DICOM Support for angiographic cine loops.

2.8 Image Display Workstations

Two categories of PACS workstations are required:

• a diagnostic workstation (DWS) primarily located in the radiology department and used for primary interpretation, and

• a review workstation (RWS) primarily for use in the clinical departments and outpatient clinics.

Whenever the phrase “workstation” or “user interface” is used in a requirement without specifically mentioning the type of workstation, the requirement is applicable to both workstation types.

A third workstation type (WWS) is required to provide access to PACS data via a web server. This section does not apply to the WWS. The requirements for this workstation are documented in Section 2.10.

2.8.1 Configuration

2.8.1.1 Two classes of workstation monitors shall be available:

Class A: Spatial Resolution approximately 2560 x 2048

Class C: Spatial Resolution approximately 1024 x 1280

2.8.1.2 DWS shall support 2 or 4 monitors of Class A or Class C.

2.8.1.3 RWS shall support 1 or 2 monitors of Class C.

2.8.1.4 A slave monitor auxiliary output connection shall be available as an option to reproduce the same single image on multiple monitors of the same type as on the workstation.

2.8.1.5 A video signal conversion feature shall be available as an option to provide NTSC video from a RWS to allow connection to a VCR.

2.8.2 Monitors

2.8.2.1 Workstation monitors shall display no fewer than 256 shades of gray (8 bits depth).

2.8.2.2 The video refresh rate shall be greater than or equal to 66 Hz for a class A monitor and 72 Hz for a class C monitor.

2.8.2.3 Maximum monitor brightness shall be greater than or equal to 60 foot-Lamberts for a class A monitor and 80 foot-Lamberts for a class C monitor.

2.8.2.4 The monitor shall have less than 15% brightness uniformity degradation from the center to the periphery.

2.8.2.5 The monitor shall have less than 3% nonlinearity from center to periphery.

2.8.2.6 The monitor shall have less than 3% geometric distortion from center to periphery.

2.8.2.7 The electron beam spot size shall vary less than 20% from the center to any corner of a rectangle 1/2" inside the perimeter of the monitor.

2.8.3 Monitor Calibration

2.8.3.1 Brightness and contrast adjustment range of the monitors shall support matching of the monitor grayscale displays to less than 5%.

2.8.3.2 The three-month drift of monitor brightness and contrast shall be less than 5%.

2.8.3.3 It shall be possible to assure calibration of all monitors with respect to contrast, intensity and spatial resolution.

2.8.3.4 The vendor shall supply a QC procedure and any required images and calibration equipment to assure that the test and calibration requirements in this Section are met.

2.8.3.5 Before the beginning of the acceptance test, a preventive and corrective maintenance program shall be provided and hospital personnel trained to ensure that monitor specifications are within acceptable limits.

2.8.4 Performance

2.8.4.1 The workstation shall display the first image of any exam in the storage system within two seconds, 90% of the time. Display time is measured from the time the user completes selection of the exam to be displayed until the last pixel of the first image is visible on the monitor.

2.8.4.2 The workstation shall display one 2K x 2.5K x 2byte image filling one monitor in two seconds.

2.8.4.3 The workstation shall display all the 512 x 512 x 2byte images at original resolution to fill a monitor in two seconds.

2.8.4.4 The workstation shall meet 2.8.4.2 and 2.8.4.3 for each monitor in an exam filling several monitors.

2.8.4.5 The workstation shall display the first 20 results of any query of the system database within two seconds, 90% of the time. Display time is measured from the time the user completes selection of the query (e.g., worklist selection) until the 20th result is visible on the monitor.

2.8.5 User Interface

2.8.5.1 The cursor shall move within and between monitors in a smooth and continuous manner under the control of a mouse or trackball pointing device with the cursor remaining visible during its movement.

2.8.5.2 The system shall enable all workstations to share a common user profile for each user which specifies at a minimum:

• window width and level presets• default display protocols• access rights and privileges

2.8.5.3 The system shall provide a mechanism for automatic logoff of a user at a workstation after a configurable period of workstation inactivity.

2.8.6 Exams, Folders, Worklists, and Queries

2.8.6.1 The system shall allow dynamically updated worklists to be created by the system administrator for a specific user or class of users and for a specific workstation. For the purpose of this RFP, a worklist is any database query which returns a list of exams or patients. Dynamically updated means that as exams change status in such a way as to change the contents of a worklist, the worklist is automatically refreshed. The requirement for dynamic updating can be satisfied by periodic polling of the database with a frequency defined by a parameter which is configurable by the system administrator.

2.8.6.2 The worklists available to a user shall be those assigned to the user, plus those assigned to the group of which the user is a member, plus those assigned to the workstation at which the user is working.

2.8.6.3 New worklists shall be definable at any time by the on-site system administrator.

2.8.6.4 The proposal shall include a description of the range of worklist definitions available to the system administrator.

2.8.6.5 A worklist entry for an exam shall include at least the patient name and ID, examination procedure, exam date and time.

2.8.6.6 The system shall support worklists which display a list of exams based on queries of:

• patient name• patient ID• patient location• modality• exam status

• date and time of acquisition• recency of acquisition

2.8.6.7 The user interface shall provide an intuitive mechanism for issuing ad hoc queries (e.g. query by example, visual query).

2.8.6.8 All exams shall be accessible from every workstation, limited only by security mechanisms.

2.8.6.9 It shall be possible to request old exams from the storage system and archive.

2.8.6.10 A mechanism shall be provided to notify a member of the Radiologist Group when he opens an unread exam which is already open by another member of the Radiologist Group.

2.8.6.11 The user interface shall organise images for exams using the metaphor of a folder.

2.8.6.12 Each patient’s exams shall be automatically organised into a set of modality specific and a set of body part specific folders (e.g. CT folder, chest folder).

2.8.6.13 A mechanism shall be provided to permit a user with proper privileges to select images or exams for inclusion into one or more manually-created folders for teaching and research purposes.

2.8.6.14 A clinical folder shall be automatically created for each patient. The most recent 3 exams shall be included in this folder automatically.

2.8.6.15 A user with the proper privileges shall be able to add or delete selected images to or from the clinical folder.

2.8.7 Reports

2.8.7.1 The workstation shall allow a user with the proper privileges to display the report for any reported exam without requiring the display of its associated images.

2.8.7.2 The administrative status of any report (e.g., approved or not approved) shall be indicated when the report is displayed.

2.8.8 Exam Display and Arrangement

2.8.8.1 The workstation shall support the display of multiple images from one exam on one or more monitors.

2.8.8.2 It shall be possible to choose among multiple image display formats for the monitors of a workstation, for example: 1:1, 2:1, 4:1, 6:1, 9:1, 12:1, 15:1 and 20:1.

2.8.8.3 The workstation shall support manually rearranging the sequence of images in an exam.

2.8.8.4 The system shall provide user-selectable, user-definable protocols for display of the images of an exam where the protocols are specific to the type of exam. The intent of this requirement is to allow physicians’ preferences for display to be satisfied.

2.8.8.5 If no display protocol exists for a specific user and examination type, the system shall provide a default protocol.

2.8.8.6 Images shall be automatically presented in an upright as well as correct right/left orientation whenever the image orientation is known to the system and the orientation is not overridden by a display protocol.

2.8.8.7 The workstation shall allow a user with the proper privileges to save the information that controls the display of the images of an exam, including window width and level, display sequence, orientation, magnification, pan position, and any annotations.

2.8.8.8 Only the most recent copy of the display state shall be saved.

2.8.8.9 If an exam is displayed which has had its display state saved, that display state shall be used.

2.8.8.10 The workstation shall support the display of multiple exams simultaneously.

2.8.8.11 The system shall provide user-selectable, user-definable protocols for display of multiple exams where the protocols are specific to the types of exams being displayed together. The intent of this requirement is to support the presentation of historical studies along with a new study for diagnosis.

2.8.8.12 The system shall support rapidly moving to the next or previous exam in a worklist. The intent of this requirement is to allow the radiologist to close a currently open exam and open the next one in a worklist with the equivalent of one keystroke.

2.8.8.13 The system shall support rapidly moving to the next or previous patient in a worklist. The intent of this

requirement is to allow the radiologist to close a currently open exam and move to the next patient in a worklist with the equivalent of one keystroke.

2.8.9 Image Display and Paging

2.8.9.1 Rapid sequential paging through images of an exam displayable on a single monitor shall be provided.

2.8.9.2 Both forward and backward paging shall be supported.

2.8.9.3 If multiple image series are viewed, it shall be possible to page through the series independently.

2.8.9.4 The workstation shall support arranging groups of related images into a stack (with only the top image visible) and displaying them sequentially forward or backward, coupled to the movement of the workstation’s pointing device.

2.8.9.5 The workstation shall support linking two or three image stacks and moving through them synchronously so that the same anatomic position or image sequence position is displayed in each stack.

2.8.9.6 A cine function with a user selectable, variable frame rate of at least 10 frames per second for 512x512 images shall be provided.

2.8.9.7 The cine function shall support the display of multiple stacks synchronously.

2.8.10 Grayscale Operations

2.8.10.1 The workstation shall provide dynamic window width and level through the entire image grayscale dataset.

2.8.10.2 The window width and level function shall be applicable to a single image, selected images, all images, or to a specified region of interest on a single monitor. Satisfaction of the region of interest requirement may be accomplished through, for example, the magnifying glass function.

2.8.10.3 Window width and level values shall be displayed in the converted units provided by the DICOM image header information.

2.8.10.4 The user interface shall support both the window width and level approach and the top/bottom approach, based on modality, with user-configurable assignments.

2.8.10.5 Display of the inverse grayscale of any selected region of interest shall be supported. Satisfaction of this requirement may be accomplished through, for example, the magnifying glass function.

2.8.10.6 The system shall provide at least five user-configurable window width and level defaults.

2.8.10.7 Window width and level defaults shall be user-, modality- and organ-specific.

2.8.10.8 A rapid method to select among default window width and level values shall be provided. The intent of this requirement is to allow the user to jump between, for example, bone windows and soft tissue windows in CT using function keys.

2.8.10.9 If an image is received from a modality along with a window width and level for viewing, the window width and level parameters shall be used for the initial display on the workstation.

2.8.10.10 If an image is displayed for which no window width and level is available, the workstation shall select a set of values which at least make the image visible as a starting point for subsequent manual changes.

2.8.10.11 It shall be possible to preset and to easily change window width and level defaults for each user.

2.8.11 Image Orientation, Zoom, Pan, and Magnifying Glass

2.8.11.1 The workstation shall allow sequential 90 degree clockwise and counter-clockwise rotation of any image as well as flip in the horizontal and vertical axes.

2.8.11.2 It shall be possible to reorient a single image, selected images, or all images in one operation.

2.8.11.3 The workstation shall be capable of enlarging an image up to at least 4x by replication of pixel values.

2.8.11.4 The workstation shall be capable of enlarging an image up to at least 4x by interpolation of pixel values.

2.8.11.5 It shall be possible to zoom a single image, selected images, or all images in one operation.

2.8.11.6 Zoomed images shall be repositionable by panning (roaming) the image within the area allocated for display of the image.

2.8.11.7 When the actual image size is greater than the monitor resolution or the resolution of the available display window, it shall be possible to reposition (roam) the image in the window dynamically and interactively.

2.8.11.8 When the actual image size is greater than the monitor resolution or the resolution of the available display window, it shall be possible to map the image to the display area by subsampling. The intent of this requirement is to assure that, for example, a CR image can be minified to fit on a class C monitor to provide an overview. Specific minification commands in addition to a “fit-to-window” command (e.g., minify by one-half, etc.), while not required, are acceptable.

2.8.11.9 When zooming an image, the original image dataset shall be used. The intent of this requirement is to assure that zooming a minified image will provide additional resolution up to that of the originally acquired image.

2.8.11.10 The workstation shall include a user-sizeable magnifying glass function which supports the options of variable magnification up to at least 4x, internal window width and level, and grayscale inversion.

2.8.11.11 When applying the magnifying glass to an image, the original image dataset shall be used. The intent of this requirement is to assure that magnifications of a minified image will provide additional resolution up to that of the originally acquired image.

2.8.12 Region of Interest, Distance, and Angle Measurements

2.8.12.1 The workstation shall compute point-to-point measurements with automatically calibrated, user-selectable scales (mm, cm, or pixels).

2.8.12.2 The workstation shall support angle measurement.

2.8.12.3 The workstation shall support region of interest mean (in image units, e.g., Hounsfield units for CT), standard deviation, number of pixels, and area measurement based on ellipses and freehand tracing.

2.8.12.4 The workstation shall compute and display region of interest statistics and distance/angle values for at least four regions simultaneously.

2.8.12.5 The workstation shall provide a means for selecting surgical prosthesis sizes by supporting the placement of graphical surgical templates on the images as overlays and allowing their repositioning by translation and rotation.

2.8.13 Image Annotation

2.8.13.1 The workstation shall provide tools allowing the user to position and orient multiple instances of text and graphics (lines, arrowheads, and circles) for image annotation.

2.8.13.2 It shall be possible to toggle the display of image annotation on and off.

2.8.14 Image Identification

2.8.14.1 The workstation shall display along with each image at least the following patient data, where appropriate for the image and modality:

• patient name• patient ID• exam date and time• image orientation• kVp• mAs• pulse sequence• slice position• image or slice number

2.8.14.2 The workstation shall allow the user to toggle the display of image identification text on and off.

2.8.14.3 The workstation shall allow the user to turn off all image identification text except image or slice number.

2.8.14.4 The workstation shall provide a function to display the entire contents of the DICOM header for a selected image.

2.8.15 Utility Functions

2.8.15.1 The workstation shall be capable of reversing the last executed command, or, for those commands which are not reversible, the non-reversible commands shall warn the user in advance.

2.8.15.2 During the execution of a time-consuming function, the workstation shall indicate that the system is working.

2.8.15.3 If the workstation stores images locally, it shall provide a function to automatically manage its local storage, for a user with the proper privileges, to allow the user to protect selected images from deletion.

2.8.15.4 The workstation shall include automatic screen blanking and power saving with a selectable time limit.

2.8.16 Control of Hard Copy Printing

2.8.16.1 The workstation shall allow users with the proper privileges to print exams on any image printer connected to the network.

2.8.16.2 Requests for printing shall not compromise workstation operation or performance.

2.8.16.3 The workstation shall allow the user to choose from multiple image formats: 1:1, 2:1, 4:1, 6:1, 9:1, 12:1, 15:1 and 20:1.

2.8.16.4 The workstation shall allow the user to arrange the images of the examination within the selected image format.

2.8.16.5 The workstation shall provide a function which displays the status of image printers on the network, including the print queue and the status (e.g., on-line, off-line, out-of-film, etc.).

2.8.16.6 The workstation shall allow the user to produce multiple copies of the same image with one request, up to a maximum limit specific to the user.

2.8.16.7 The workstation shall allow the user to cancel a print request which he has previously entered.

2.8.16.8 The system shall enable logging of print jobs for accounting purposes, including at least the requester’s name, the number of films, the exam identification, the date and time the exam was printed, and the printer which was used.

2.8.16.9 Identification of the requester, date, time, and number of the film sheet shall be printed on the border of the film.

2.9 Film Printers

Two categories of fillm printers are required:

• high quality laser printers to be located in the radiology department

• dry silver printers primarily for use in the surgical departments for producing materials to be taken into the OR.

2.9.1 The system shall include both laser film printers and dry silver printers.

2.9.2 Both kinds of printers shall support the DICOM Print Service Class as a Service Class Provider (SCP).

2.9.3 Both kinds of printers shall provide multiple image formats, including 1:1, 2:1, 4:1, 6:1, 9:1, 12:1, 15:1, and 20:1.

2.9.4 Both kinds of printers shall produce multiple copies of the same image with one request initiated at the user’s workstation.

2.9.5 Both kinds of printers shall print each image as it was acquired or modified by a workstation, including image overlays and textual data.

2.9.6 Both kinds of printers shall print the identification of the requester, date, year, hour and number of the sheet on the film.

2.9.7 The laser printer shall have the capability to record images in at least two image sizes, including 14” x 17” and 10” x 12”. This requirement may be met through the use of appropriately sized film magazines, at least two of which are online simultaneously.

2.9.8 The laser printer shall zoom images when necessary to fit in an assigned multiformat space using a cubic spline interpolation algorithm.

2.9.9 Image selection and film format on the laser printer shall be controllable from the workstation at which the print request is created or locally by keypad.

2.9.10 The laser printer shall be equipped with interlocks or warning lights that prevent double exposure, exposures with film in the wrong position, incompatible film sizes, and improper film insertion and removal.

2.9.11 The laser printer supply magazines shall hold 100 films and shall be daylight loading.

2.9.12 The laser printer shall include an attached film processor, and the combination shall have a throughput of at least 60 sheets of 14” x 17” film per hour.

2.9.13 A digital test pattern (SMPTE or equivalent) shall be provided for quality assurance and device verification.

2.9.14 The laser printer shall allow the operator to adjust image contrast and density manually.

2.9.15 The laser printer shall automatically perform a calibration test on startup and at the request of the operator.

2.9.16 The laser printer shall include a self diagnostic capability which shall indicate at least the following error and system status conditions: film low, film empty, memory full, film feed error, printing, and alarm.

2.10Web Servers and Web Workstations

The hospital intends to provide access to PACS information in locations where PC workstations are already installed. The preferred implementation is to use world wide web technology to provide access through the hospital’s local area network to hospital-supplied workstations running standard web browsers. The web workstation will be referred to as WWS in this document. Remote web workstations at non-imaging sites, e.g. radiologists’ homes, will access exams and images using telecommunications access to be provided as part of the hospital’s communications system.

2.10.1 The system shall include at least one web server and web pages (and applets, if required) which provide access to all PACS information through the PACS local area network or through the hospital’s local area network.

2.10.2 The system shall include as many web servers as are required to support the image review load specified in Appendices I and II, assuming 25% of the total load is to be retrieved through the web.

2.10.3 The system shall allow a PC supplied by the hospital to access the web pages (and applets, if required) using either Netscape Navigator or Microsoft Internet Explorer.

2.10.4 The proposal shall describe the sizing rules for web servers, e.g., the number of active WWS which may be supported by one web server.

2.10.5 The proposal shall include a specification of the minimum hardware configuration for a WWS which provides the functionality required in this section.

2.10.6 The proposal shall include a specification of the minimum hardware configuration for a WWS which provides 4-second retrievals of 1024x1024x2byte images from the web server.

2.10.7 The WWS shall allow a user to log into and log off from the system.

2.10.8 The WWS shall support all worklists supported by the diagnostic and review workstations.

2.10.9 The WWS shall allow selection of an exam from a worklist.

2.10.10 The WWS shall allow display of the report for the selected exam.

2.10.11 The WWS shall display images for the selected exam using the window width and level, magnification, center, orientation, and annotation information stored for each image.

2.10.12 The WWS shall support changing the window width and level on individual images as well as on groups of selected images.

2.10.13 The WWS shall support magnification and panning (roaming) of individual images.

2.10.14 The WWS shall support reorientation (flip and rotate) of individual images.

3 System Integration

3.1 Operations

3.1.1 The proposal shall specifically include descriptions of the system's operation under the scenarios described in Section 1.2.

3.1.2 The proposal shall include a description of the staff required to operate the system, their necessary qualifications, and the tasks the staff will perform.

3.2 Reliability

3.2.1 The system shall be designed with reasonable redundancy so that no single point of failure can cause a major breakdown of radiology service.

3.2.2 The system shall protect against the loss of acquired images and data.

3.2.3 If a failure interrupts or disables image acquisition, the system shall provide a means to enter the missed images from the imaging equipment at a later time.

3.2.4 Where appropriate to guarantee against loss of image or exam information during acquisition or storage in the PACS in the event of a power failure, the vendor shall supply an Uninteruptable Power Supply (UPS) with sufficient capacity to support the necessary equipment during the operation. This requirement is not intended to require UPS at all locations, only at those locations where a power failure would cause a loss of patient images or information. This requirement is also not intended to require that the system continue to operate for additional acquisitions during the power outage.

3.2.5 The system shall maintain a total system uptime of at least 99% monthly, and individual component uptimes of at least 95% monthly. Percentages will be calculated based on a two shift, 16 hour day. Component and system downtimes will include scheduled and unscheduled outages.

3.2.6 The proposal shall identify all components, the failure of which can cause significant loss of system functionality, e.g., inability to acquire, display, archive, or fetch exams.

3.2.7 The vendor shall describe the failover strategies to be employed when each system component fails, including interfaces to external information systems.

3.2.8 Each failover strategy shall include detailed descriptions of:

• how the failure will be detected• how much of the system will remain operational

during the failure• how the function of the failed component will be

performed during the failure

• how the system will be restored after the failure has been corrected.

4 Purchased Components

4.1 Configuration

4.1.1 The vendor shall supply and install the equipment listed in Appendix III at the indicated locations.

4.1.2 The vendor shall supply and install a communication network as required to support the equipment listed in Appendix III.

4.2 Startup Kits and Supplies

4.2.1 The vendor shall supply all necessary media for the on-line portion of the archive system necessary to support 90 days’ operation of the system at the capacity indicated in Appendix I.

4.2.2 The vendor shall provide a list of approved vendors of any required system supplies.

5 Installation

5.1 Hospital-Furnished Equipment and Services

The hospital intends to centralize the core components of the system in a computer room to provide maximum security and to facilitate the task of system administration. The hospital will renovate the space required to provide the computer room.

5.1.1 The proposal shall specify those core system components which are appropriate to centralize in a computer room with limited access for system administration and maintenance personnel.

5.1.2 The proposal shall specify the required characteristics of the central computer facility to be provided by the hospital for the system. These characteristics are expected to include the space and utility requirements as listed in 6.3.1 as well as any additional requirements such as physical layout constraints which are required by the vendor’s system.

5.2 Supplier-Furnished Equipment and Services

5.2.1 The vendor shall be responsible for all renovation of hospital facilities needed to support system installation except as noted in Section 6.1. This requirement should be interpreted to include construction, HVAC, and plumbing.

5.2.2 The selection of subcontractors involved in renovation shall be approved by the hospital.

5.2.3 All construction plans shall be approved by the hospital prior to implementation.

5.2.4 The vendor shall be responsible for network installation as noted in 4.1.2.

5.2.5 A network intallation plan detailing cable runs, cable type, termination, concentrators, hubs, bridges, and all other network devices shall be prepared by the vendor and approved by the hospital prior to implementation.

5.2.6 The vendor shall provide all modality interfacing solutions in compliance with the requirements of Section 2.7. If software or hardware upgrades of existing modalities are necessary, the vendor is required to identify the necessary upgrades in the proposal.

5.3 Environmental Requirements

5.3.1 The proposal shall specify for each component to be supplied the following utility requirements:

• physical dimensions• physical space required for operation• physical space required for service• weight• building structural requirements• raised floor requirements• power requirements• power conditioning requirements, including the

need for UPS• air-conditioning requirements• exhaust requirements• water requirements• waste requirements• chemical requirements.

The vendor is offered the opportunity to make measurements on site to determine whether local power requires special conditioning.

The information above may be included in a single table or as part of the individual data sheets required in section 11.

5.4 Installation Facilities

5.4.1 The proposal shall include a list of the facilities required for installation support, including:

• loading dock• material storage• workshop space• office space• communications (telephone, fax, etc.)• shipping and receiving department support• anything else

6 System Acceptance

6.1 Verification that the required equipment and services meet the RFP requirements shall be accomplished through an Acceptance Test.

6.2 The vendor shall provide all required materials and supplies for the acceptance test.

6.3 The vendor shall submit with the proposal a complete draft acceptance test addressing every normative requirement in the RFP. The hospital and the vendor will negotiate a final version of the acceptance test before the contract is awarded.

6.4 For each normative requirement which requires a physical test, the acceptance test shall include:

• normative requirement identification• materials to be used – films, exams from

modalities, etc.• system population – the number of patients and

exams, etc., in the database, the fraction of the storage system in use, the number of exams in the archive, the amount of local storage in use, etc.

• system load – the number of active workstations and what they are doing, the number of requests

queued for the archive, the number of messages queued from the external information system, etc.

• measurement technique – what to do to perform the test, how to make the measurement, the start and end points for timing measurements, etc.

• expected results.

7 Training

7.1 An operator’s manual shall be provided for each delivered system component.

7.2 Five sets of service manuals shall be provided for each system component type.

7.3 Two complete sets of manuals covering the operation, installation, and maintenance of all system components and explaining the operational concept of the system as a whole shall be provided.

7.4 QC procedures required to maintain operation within the requirements of this RFP shall be supplied for each component. These procedures may be included in the manuals in 7.2 or 7.3.

7.5 All manuals shall be updated appropriately to reflect each new software release and implementation phase.

7.6 The proposal shall include a comprehensive training plan which includes:

on-site training staff courses offered summary of course content frequency of course offerings training programs for: technologists,

Radiologists, administrative personnel, residents, ICU staff, ED staff, and a UMMS-appointed system administrator

continuous, computer based training materials and programs.

8 System Warranty and Maintenance

8.1 Warranty

8.1.1 The warranty period shall be deemed to start on the earlier of successful completion of the acceptance test

or first operational clinical use of the system by the hospital.

8.1.2 The warranty period shall last 12 months.

8.1.3 The warranty period shall be extended by one month for each month the system fails to meet the reliability requirements of Section 3.3.

8.1.4 The warranty shall cover parts and labor.

8.1.5 During the warranty period, the hospital shall have the option of requiring replacement of any component which does not maintain at least 80% availability during the 0500-1800 time period on weekdays for any one-month period.

8.1.6 During the warranty period, the vendor shall provide the following operations support: one full-time, on-site field engineer and one full-time, on-site system administrator.

8.1.7 The vendor shall identify in the proposal the space and other facilities which the hospital will have to make available during the warranty period.

8.1.8 Preventive maintenance and software installation shall be scheduled not to occur during the 0500-1800 time period on weekdays.

8.2 Maintenance

8.2.1 The vendor shall include in the proposal an offer of a one-year maintenance contract with the characteristics described in the rest of this section, specifying the ordering and payment terms.

8.2.2 The vendor shall include in the proposal an offer of a five-year maintenance contract with the characteristics described in the rest of this section, specifying the ordering and payment terms.

8.2.3 The vendor shall identify in the proposal the space and other facilities which the hospital will have to make available during the warranty period.

8.2.4 The maintenance contract shall be extended by one month for each month the system fails to meet the reliability requirements of Section 3.3.

8.2.5 The maintenance contract shall cover parts and labor.

8.2.6 During the maintenance period, the hospital shall have the option of requiring replacement of any component which does not maintain at least 80% availability during the 0500-1800 time period on weekdays for any one-month period.

8.2.7 During the maintenance period, the hospital shall have the option of replacing without cause one-quarter of the monitors in the system in any one-year interval.

8.2.8 The maintenance contract shall cover the following operations support: one full-time, on-site field engineer, sufficient part-time and/or off-site personnel to provide 24 hour per day, 7 day per week coverage.

8.2.9 Maintenance and support response time shall be 20 minutes or less during the 0600-1800 time period and 60 minutes or less during the remainder of the day. Response time is measured from the time the field engineer on call is paged until support personnel are on-site and actively working on the problem.

8.2.10 Preventive maintenance and software installation shall be scheduled not to occur during the 0500-1800 time period on weekdays.

8.3 Spare Parts

8.3.1 The vendor shall describe in the proposal the spare parts stocking strategy which will be employed during the warranty period, including on-site spares and any company depots to be maintained.

8.3.2 The vendor shall provide a guarantee that the hospital will be able to purchase any required spare parts from the vendor for five years.

9 Contract Administration

The administrative point of contact at the hospital for all contractual matters is <grand fromage>.

9.1 The vendor’s proposal shall identify a single administrative point of contact for future negotiations and project planning.

10 Proposal Structure

10.1 The proposal shall include: • system pricing

• technical description of the product offering and the specific configuration for the hospital

• individual responses to each normative requirement using the requirement identification numbers in this RFP

• data sheets for all components• technical reports and documentation necessary to

validate the vendor’s claims• information as required by other requirements in

this RFP.

10.2 One printed copy of the proposal shall be submitted.

10.3 The proposal shall also be submitted as a Microsoft Word and/or Excel files on 3.5” High Density diskettes. Copies of the data sheets and technical reports and documentation need not be included on the diskettes.

10.4 With the proposal, or at any time before submission of the proposal, the vendor shall provide two copies of the workstation operator’s manual, one copy of the CR acquisition system operator’s manual, and one copy of the system administrator’s manual.

10.5 The proposal shall explicitly identify every normative requirement of this RFP which is not met by the vendor’s offering. If a requirement will be met in the future, the vendor may provide a schedule of commercial availability for future enhancements which redress the non-compliance, together with their prices. If a requirement will not be met by a planned enhancement of the system, the vendor may explain the impact of the deficit on overall system functionality.

Appendix I Procedure Volume Analysis

Appendix II Image Request Statistics

This appendix records the rationale for the factors of 27 and 6 used in the performance requirements in the RFP. The assumption is made that the diagnostic request statistics from Stewart, et. al., IEEE Eng. in Med. & Biol., Mar. 1993, are applicable generally.

Requests per image:

Diagnostic requests:

First 3 days of hospital stay = 10

Next 6 days of hospital stay = 4

Rest of first year = 3 ( = a)

Outpatient studies = 2 ( = b)

PACS operational load:

Initial acquisition = 1

QC / exam verification = 1

Initial archival = 1

Dearchivals = 5 ( = a + b)

Total storage system requests per image = 27

Total archive system requests per image = 6

Appendix III Table of Components and Locations

The following component names and definitions are used in the table below:

ARC: archive system

CR: CR reader

DB: database computer

DWS: diagnostic workstation

EIS: external information system interface

FD: film digitizer

LP: laser printer

M: modality interface

RWS: review workstation

STS: short-term storage system

WWS: web workstation

Monitor types are defined as:

A: 2560 x 2048 (approximately), monochrome, portrait mode

B: 1280 x 1024 (approximately), monochrome, portrait mode

C: 1024 x 1280 (approximately), monochrome, landscape mode

Workstations are defined by the nomenclature:

<name> - <number of monitors> <type of monitor>

For example, a diagnostic workstation with four 2.5K x 2K monitors is denoted, DWS-4A.

The approximate locations of network drops within rooms are identified in the table by compass point.

Table of Components and Locations

Appendix IV Table of Current Modalities

Service Location

Equipment Description

Appendix V Architectural Plans

The attached architectural drawings and indicated equipment locations are for the convenience of the vendor in preparing the proposal. The vendor is offered the opportunity to make site visits as necessary to refine estimates of installation cost. Appendix III shall take precedence as the normative requirement of purchased equipment and installation locations.

Appendix VI Corporate Network

The attached network drawings and descriptions are for the convenience of the vendor in preparing the proposal. The vendor is offered the opportunity to make site visits as necessary to refine estimates of installation cost.