Picture Archiving and Communication System (PACS)

Source: Wikipedia: Picture Archiving and Communication System

Picture archiving and communication system

From Wikipedia, the free encyclopedia
Jump to: navigation, search
An image as stored on a picture archiving and communication system (PACS)
The same image following contrast adjustment, sharpening and measurement tags added by the system

In medical imaging, a picture archiving and communication systems (PACS) is a combination of hardware and software dedicated to the short and long term storage, retrieval, management, distribution, and presentation of images. Electronic images and reports are transmitted digitally via PACS; this eliminates the need to manually file, retrieve, or transport film jackets. The universal format for PACS image storage and transfer is DICOM (Digital Imaging and Communications in Medicine). Non-image data, such as scanned documents, may be incorporated using consumer industry standard formats like PDF (Portable Document Format), once encapsulated in DICOM. A PACS consists of four major components: the imaging modalities such as CT and MRI, a secured network for the transmission of patient information, workstations for interpreting and reviewing images, and archives for the storage and retrieval of images and reports. Combined with available and emerging Web technology, PACS has the ability to deliver timely and efficient access to images, interpretations, and related data. PACS breaks down the physical and time barriers associated with traditional film-based image retrieval, distribution, and display.

* 1 Types of images
* 2 Uses
* 3 Architecture
* 4 Querying
* 5 Image retrieval
* 6 Image archival and backup
* 7 Integration
* 8 DICOM Viewers
* 9 History
* 10 Regulatory concerns
* 11 See also
* 12 References
* 13 External links

[edit] Types of images

Most PACSs handle images from various medical imaging instruments, including ultrasound (US), magnetic resonance (MR), positron emission tomography (PET), computed tomography (CT), endoscopy (ENDO), mammograms (MG), digital radiography (DR), computed radiography (CR) etc. (see DICOM Application areas).
[edit] Uses

PACS has four main uses:

* Hard copy replacement: PACS replaces hard-copy based means of managing medical images, such as film archives. With the decreasing price of digital storage, PACSs provide a growing cost and space advantage over film archives in addition to the instant access to prior images at the same institution. Digital copies are referred to as Soft-copy.
* Remote access: It expands on the possibilities of conventional systems by providing capabilities of off-site viewing and reporting (distance education, telediagnosis). It enables practitioners in different physical locations to access the same information simultaneously for teleradiology.
* Electronic image integration platform: PACS provides the electronic platform for radiology images interfacing with other medical automation systems such as Hospital Information Systems (HIS), Electronic Medical Records Systems (EMR), Practice Management Systems, and Radiology Information Systems (RIS).
* Radiology Workflow Management: PACS is used by radiology personnel to manage the workflow of patient exams.

PACS is offered by virtually all the major medical imaging equipment manufacturers, medical IT companies and many independent software companies. Basic PACS software can be found free on the Internet.
[edit] Architecture

Typically a PACS consists of a central server that stores a database containing the images connected to one or more clients via a LAN or a WAN which provide or utilize the images.

More and more PACS include web-based interfaces to utilize the Internet as their means of communication, usually via VPN (Virtual Private Network) or SSL (Secure Sockets Layer). The client side software is often using ActiveX, JavaScript and/or Java. These are considered only suitable for very small practices that do not view studies containing more than one or two images, as web-based viewers are sandboxed by the parent web browser and cannot allocate enough memory to view even modestly sized image data sets. Some systems [1] show compressed images and run completely within the browser (no software to download). More robust PACS clients are full applications which can utilize the full resources of the computer they are executing on.

Definitions vary, but most claim that for a system to be truly web based, each individual image should have its own URL. [citation needed]

Client workstations can use local peripherals for scanning image films into the system, printing image films from the system and interactive display of digital images. PACS workstations offer means of manipulating the images (crop, rotate, zoom, window, level and others).

Modern radiology equipment and modalities feed patient images directly to the PACS in digital form. For backwards compatibility, most hospital imaging departments and radiology practices employ a film digitizer.

PACS image backup is a critical, but sometimes overlooked, part of the PACS Architecture (see below). HIPAA requires that backup copies of patient images be made in case of image loss from the PACS. There are several methods of backing up the images, but they typically involve automatically sending copies of the images to a separate computer for storage, preferably off-site.
[edit] Querying

The communication with the PACS server is done through dicom objects that are similar to dicom images, but with different tags. A query typically looks as follows:

* The client establishes the network connection to the PACS server.
* The client prepares a query object which is an empty dicom dataset object.
* The client fills in the query object with the keys that should be matched. E.g. to query for a patient ID, the patient ID tag is filled with the patient's ID.
* The client creates empty tags (tags with zero length string values) for all the tags it wishes to receive from the server. E.g. if the client wishes to receive an ID that it can use to receive images (see image retrieval) it should create the tag SOPInstanceID (0008,0018) in the query object.
* The query object is sent to the server.
* The server sends back to the client a list of response dicom objects.
* The client extracts the tags that are of interest from the response dicom objects.

[edit] Image retrieval

Images are retrieved from a PACS server through a C-MOVE request, as defined by the DICOM network protocol. This request specifies where an image instance should be sent through an identifier known as the destination AETITLE. The server must be configured about the mapping of the AETITLE to a TCP/IP address and port, and as a consequence the server must know in advance all the AETITLEs that it will ever be requested to send images to.
[edit] Image archival and backup

Digital medical images are typically stored locally on a PACS for retrieval. It is important (and required in the USA by the Security Rule's Administrative Safeguards section of HIPAA) that facilities have a means of recovering images in the event of an error or disaster. While each facility is different, the goal in image backup is to make it automatic and as easy to administer as possible. The hope is that the copies won't ever be needed. But, as with other disaster recovery and business continuity planning, they need to be available if needed.

Ideally, copies of images should be streamed off-site as they are created. (If using the internet, the Security Rule's Technical Safeguards section of HIPAA requires that the images be encrypted during transmission.) Depending on bandwidth and image volume, this may not be practical. Other options include removable media (hard drives, DVDs or other media that can hold many patients' images) that is physically transferred off-site. The content of these copies needs to be protected from exposure to unauthorized personnel[1].

Images may be stored both locally and remotely on off-line media such as tape or optical media, or partially or exclusively on hard disks ("all spinning") media. The latter is becoming more common. The hard drives may be configured and attached to the PACS server in various ways, either as Direct-Attached Storage (DAS), Network-attached storage (NAS), or via a Storage Area Network (SAN).

However the storage is attached, the drives themselves are usually configured as a Redundant Array of Inexpensive (or Independent) Discs RAID, which may be configured to provide appropriate combination of faster disk access or protection against the failure of one (or even two) discs in the physical RAID array. Typically, failed drives may be physically replaced (hot swapping) without interruption of service. Since costs of computers has fallen, some sites opt for fully redundant Archives, rather than just protecting the drives through RAID. Further, RAIDs are fragile and can be rendered useless by one erroneous hit on the controller.

Data stored on disk may also be backed up to tape or optical media or copied, in real time, to a slower, inexpensive disc in another machine at another location. Some sites make two such backups and remove them from the site on a rotating basis.

In the event that it is necessary to reconstruct a PACS partially or completely from the backup images, some means of rapidly transferring all of its images back to the PACS is required, preferably whilst the PACS continues to receive and provide current images.

The backup infrastructure may also be capable of supporting the migration of images to a new PACS.
[edit] Integration
A chest image displayed via a PACS

A full PACS should provide a single point of access for images and their associated data. That is, it should support all digital modalities, in all departments, throughout the enterprise.

However, until PACS penetration is complete, individual islands of digital imaging not yet connected to a central PACS may exist. These may take the form of a localized, modality-specific network of modalities, workstations and storage (a so-called "mini-PACS"), or may consist of a small cluster of modalities directly connected to reading workstations without long term storage or management. Such systems are also often not connected to the departmental information system. Historically, Ultrasound, Nuclear Medicine and Cardiology Cath Labs are often departments that adopt such an approach.

More recently, Full Field Digital Mammography (FFDM) has taken a similar approach, largely due to the large image size, highly specialized reading workflow and display requirements, and intervention by regulators. The rapid deployment of FFDM in the US following the DMIST study has led to the integration of Digital Mammography and PACS becoming more commonplace.

All PACS, whether they span the entire enterprise or a localized within a department, should also interface with existing hospital information systems: Hospital information system (HIS) and Radiology Information System (RIS). There are several data flowing into PACS as inputs for next procedures and back to HIS as results corresponding inputs:

In: Patient Identification and Orders for examination. These data are sent from HIS to RIS via integration interface, in most of hospital, via HL7 protocol. Patient ID and Orders will be sent to Modality (CT,MR,etc) via DICOM protocol (Worklist). Images will be created after images scanning and then forwarded to PACS Server. Diagnosis Report is created based on the images retrieved for presenting from PACS Server by physician/radiologist and then saved to RIS System.
Out: Diagnosis Report and Images created accordingly. Diagnosis Report is sent back to HIS via HL7 usually and Images are sent back to HIS via DICOM usually if there is a DICOM Viewer integrated with HIS in hospitals (In most of cases, Clinical Physician gets reminder of Diagnosis Report coming and then queries images from PACS Server).

Interfacing between multiple systems provides a more consistent and more reliable dataset:

* Less risk of entering an incorrect patient ID for a study – modalities that support DICOM worklists can retrieve identifying patient information (patient name, patient number, accession number) for upcoming cases and present that to the technologist, preventing data entry errors during acquisition. Once the acquisition is complete, the PACS can compare the embedded image data with a list of scheduled studies from RIS, and can flag a warning if the image data does not match a scheduled study.
* Data saved in the PACS can be tagged with unique patient identifiers (such as a social security number or NHS number) obtained from HIS. Providing a robust method of merging datasets from multiple hospitals, even where the different centers use different ID systems internally.

An interface can also improve workflow patterns:

* When a study has been reported by a radiologist the PACS can mark it as read. This avoids needless double-reading. The report can be attached to the images and be viewable via a single interface.
* Improved use of online storage and nearline storage in the image archive. The PACS can obtain lists of appointments and admissions in advance, allowing images to be pre-fetched from off-line storage or near-line storage onto online disk storage.

Recognition of the importance of integration has led a number of suppliers to develop fully integrated RIS/PACS. These may offer a number of advanced features:

* Dictation of reports can be integrated into a single system. The recording is automatically sent to a transcript writer's workstation for typing, but it can also be made available for access by physicians, avoiding typing delays for urgent results, or retained in case of typing error.
* Provides a single tool for quality control and audit purposes. Rejected images can be tagged, allowing later analysis (as may be required under radiation protection legislation). Workloads and turn-around time can be reported automatically for management purposes.

[edit] DICOM Viewers

There are several DICOM viewers available both free and proprietary. Some of the DICOM viewers include: Keosys, Myrian by Intrasense, NovaPACS by Novarad, Medstrat, eFilm, K-Pacs, DICOM Works, OsiriX, Aeskulap, kradview, SureVistaVision, UniPACS, Syngo Imaging, VRRender, ImageJ and MicroDicom. Various viewers can connect directly to a PACS server or retrieve images from local storage. Of note, OsiriX, Aeskulap and kradview are open-source DICOM viewers. 3d Fused images (PET/CT, SPECT/CT, PET/MR) can also be displayed on Pacs systems using viewers such as the 3d Fusion Keosys software.
[edit] History

The principles of PACS were first discussed at meetings of radiologists in 1982. Various people are credited with the coinage of the term PACS. Cardiovascular radiologist Dr Andre Duerinckx reported in 1983 that he had first used the term in 1981.[2] Dr Samuel Dwyer, though, credits Dr Judith M. Prewitt for introducing the term.[3]

Dr Harold Glass, a medical physicist working in London in the early 1990s secured UK Government funding and managed the project over many years which transformed Hammersmith Hospital in London as the first filmless hospital in the United Kingdom.[4] Dr Glass died a few months after the project came live but is credited with being one of the pioneers of PACS.
[edit] Regulatory concerns

In the US PACS are classified as Medical Devices, and hence if for sale are regulated by the USFDA. In general they are subject to Class 2 controls and hence require a 510(k), though individual PACS components may be subject to less stringent general controls[5]. Some specific applications, such as the use for primary mammography interpretation, are additionally regulated[6] within the scope of the Mammography Quality Standards Act.
[edit] See also

* X-ray
* Digital Mammography and PACS
* Medical device
* Medical imaging
* Medical software
* Computed axial tomography
* Telemedicine
* Electronic health record (EHR)
* Radiology
* Radiology Information System
* Electronic Medical Record (EMR)

[edit] References

1. ^ HealthcareITnews: HHS cracks down: provider to pay $100,000 in HIPAA penalties over lost laptops. July 17, 2008, Diana Manos, Senior Editor
2. ^ Duerinckx AJ, Pisa EJ. Filmless Picture Archiving and Communication System (PACS) in Diagnostic Radiology. Proc SPIE 1982;318;9-18. Reprinted in IEEE Computer Society Proceedings of PACS'82, order No 388.
3. ^ Samuel J. Dwyer III. A personalized view of the history of PACS in the USA. In: Proceedings of the SPIE, "Medical Imaging 2000: PACS Design and Evaluation: Engineering and Clinical Issues", edited by G. James Blaine and Eliot L. Siegel. 2000;3980:2-9.
4. ^ Bryan S, Weatherburn GC, Watkins JR, Buxton MJ (1999). "The benefits of hospital-wide picture archiving and communication systems: a survey of clinical users of radiology services". Br J Radiol 72 (857): 469–78. PMID 10505012.
5. ^ USFDA (27 Jul 2000). "Guidance for the Submission Of Premarket Notifications for Medical Image Management Devices". http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm073720.htm. Retrieved 11 Feb 2010.
6. ^ USFDA (30 May 2008). "Guidance for Industry and FDA Staff: Display Accessories for Full-Field Digital Mammography Systems-Premarket Notification (510(k)) Submissions". http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm107549.htm. Retrieved 11 Feb 2010.

[edit] External links

* Teleradiology, PACS and DICOM Software List of free PACS and DICOM software available on the web
* History of PACS
* PACS History Web Site
* USC IPILab Research Article on Backup

Retrieved from "http://en.wikipedia.org/wiki/Picture_archiving_and_communication_system"
Categories: Medical imaging | Telehealth | Health informatics | Radiology
Hidden categories: All articles with unsourced statements | Articles with unsourced statements from November 2008
Personal tools

* New features
* Log in / create account


* Article
* Discussion



* Read
* Edit
* View history



* Main page
* Contents
* Featured content
* Current events
* Random article


* About Wikipedia
* Community portal
* Recent changes
* Contact Wikipedia
* Donate to Wikipedia
* Help


* What links here
* Related changes
* Upload file
* Special pages
* Permanent link
* Cite this page


* Create a book
* Download as PDF
* Printable version


* Deutsch
* Español
* فارسی
* Français
* 한 국어
* Italiano
* Nederlands
* ‪Norsk (bokmål)‬
* Português
* Русский
* Svenska
* Türkçe
* 中文

* This page was last modified on 24 May 2010 at 19:59.
* Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
* Contact us

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License