PACS, a widely known acronym in the radiology world, is familiar to every graduating radiology student poised to be a radiologist. Yet, numerous medical-imaging diagnostic centers continue to operate without PACS software, either unable or unwilling to keep up with the evolving trend in the healthcare market. So what exacty is PACS? Why is it so important?
This article explores the evolution of PACS from its early beginnings in radiology conferences during the 1980s to becoming a fully-fledged sector driving transformative change in the present day.
What is PACS?
For those of who are still trying to wrap their heads around the acronym, we’ll simplify it for you a bit. PACS stands for ‘Picture Archiving and Communication Systems’ and simply put, is an electronic way of storing images and reports over the conventional radiological film. Medical images that CT or MRI machines generate can be archived, stored and transmitted digitally instead of the orthodox method of filing, retrieving and transporting the physical film.
PACS architecture typically consists of four main components:
- An imaging modality (like X-Ray/CT/MRI)
- Secure network (such as LAN) for the images to be uploaded and transferred to the database
- A workstation to allow the radiologist to view the scans and analyse them
- An archive for secure storage of image and relevant, supporting documents
Combined together, they completely eliminate the need for physical printing of all images for the radiologist’s diagnosis, streamlining the radiologist workflow to a considerable extent.
The pre-PACS era (pre 1980s)
Radiology has been practised as a science since the late nineteenth century. In those times, early radiologists relied on film-based methods to generate images. These included:
- Film creation, where medical images were captured on specialised X-ray sensitive film
- Film processing, where they would be developed in a chemical processor to make these images permanent and visible
- Film storage, where these developed films would then be stored in archiving rooms
- Film retrieval, where these films would later be retrieved and viewed by the radiologist on a backlit surface to diagnose the patient
This manual process obviously posed a multitude of problems, first of them was that the process was time-consuming, required a huge physical storage space, possessed the risk of film damage/loss and was ineffective in handling patient emergencies. The medical community was on a lookout for something novel, and with computers becoming mainstream, they turned to ‘electronic images’ for their rescue.
The inception of PACS (early 1980s)
PACS, as a concept, had been discussed in multiple radiology conferences, but movement toward reality started in the early 1980s. With funding from early-adopters like the US Defence Agency, the first large scale PACS installation took place at the University of Kansas in 1982. The system, known as Kansas University Medical Centre (KUMC) Image Archive Centre, was developed by a trio of doctors, viz- Dr. James Getty, Dr. Kenneth Persons and Dr. Herber Smith.
Soon, other similar installations at medium-scale started across the US and Europe. However, all PACS installations faced one major problem- it was difficult for medical images generated on one vendor’s device to be transferred or displayed on another vendor’s hardware. A similar issue was being faced in software at the time- the presence of multiple OS and softwares led to multiple file types, and it became difficult to share files across systems. Adobe, with its vision for disruption, introduced the standardised file format named ‘PDF’ and also developed the first ever associated pdf-viewer, as a step in the direction of platform-independence and standardisation.
No such standard was in place for medical images, and the community soon realised the need for the same.
The early-PACS era (1980s-late 1990s)
In 1983, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) collaborated to pioneer a medical image format standard called ‘Digital Imaging and Communications in Medicine’ or DICOM. Chaired by renowned radiologist Dr. David Avrin, the DICOM committee also introduced the associated ‘DICOM-viewer’ for opening files in the DICOM format, with the stable release being DICOM 3.0 in 1993.
But does creation of a robust system alone allow for easy adoption across the sector? Definitely not! While the technology, standard, and economics were in place by the late 1990s for the PACS revolution, PACS companies faced the challenge of convincing radiologists and hospitals about its worthiness as an investment. Overcoming initial resistance, PACS companies employed effective communication methods like seminars, success stories, proof-of-concept demos, collaboration with OEMs, and technology support to drive early adoption.
Workstation-based PACS (mid 2000s – mid 2010s)
PACS companies in this era focussed on providing multiple features in their DICOM viewers. While the PACS architecture couldnt change much, companies differentiated on the features and the speed of processing. Significant features like eclipsing (avg HU calculator), multiplanar reconstruction (2D and 3D) and rendering were introduced and well-received. Today companies like Medixant (RadiAnt viewer, 2009), Pixmeo (OsiriX, 2010) are benchmarks in DICOM viewers, offering a vast variety of post-processing capabilities. They however possess a significant disadvantage: the radiologist is required to be present at the workstation and has no way of remote-access for analysing the images. The question that thus presents itself is: in a world that is constantly shifting towards convenience-first and mobile-first solutions, are workstation-based PACS softwares which confine radiologists’ mobility the real present of the technology?
The concept of cloud-based PACS (late 2010s – present)
More recently, trends have been towards an adoption of cloud-based PACS, which run on remote cloud computing services. In this system, the entire deployment, storage and maintenance of the PACS software is handled by third-party professionals.
Cloud-based PACS systems provide a plethora of advantages over on-premises systems:
- Remote-access, where radiologists can now view the images on the DICOM viewer from any device- be it laptop/iPad or even their mobile phones! The quality of the images does not vary across devices and radiologists no longer need to be physically present at the workstation to analyse these images. This leads to the concept of the ‘mobile-first solution’ and the idea of the ‘zero-footprint viewer’ while also expediting patient care.
- Cost-effectiveness, where centres find it cheaper to deploy cloud-based services over on-premise hardware. The former also allows for better pricing models like the pay-per-use, unlike the initial upfront investment as required by offline viewers.
- Digital sharing, where images and reports can be shared with patients and referring clinicians as links over WhatsApp/email. This also greatly reduces the need for printing films, saving the centre a substantial cost, while also creating positive environmental impact.
- Security, where cloud-based servers are under lesser threat of malware as compared to on-site architecture. Cloud-based servers adhere to strict compliance standards and security protocols, making it tougher for them to get corrupted.
- Scalability, where higher caseload simply implies a modified pricing plan, instead of deleting old cases or upgrading storage (as in on-premise PACS softwares)
These cloud-based PACS softwares have in-turn allowed for a new market to develop, called teleradiology. Many centres now employ technicians for operating these modalities. Once generated, these images are assigned to available radiologists (who have signed up with the teleradiology company). These radiologists then interpret images, generate reports and send them back to the centre. More insights on teleradiology will be covered in an upcoming article.
The future of PACS
So, where do we go from here? Current industry professionals believe that VNA and EMR are two concepts which have already started infusing into the sector and will continue to do so in the future.
Vendor-neutral archive (VNA) provides a centralised repository for storing medical images, metadata and clinical information in an agnostic format. Unlike current PACS that are vendor-specific and may possess proprietary data formats, a VNA is designed to be vendor-neutral. This helps in interoperability (allowing collection of imaging data from across departments) as well as in data migration without hassles.
Electronic Medical Record (EMR) is a digital version of the patient’s whole history, diagnoses, treatments and other relevant data. This focuses on providing a central data-source across the institution where departments can view this data alongside the images, scheduled next appointments and billing information as well. This provides for a streamlined workflow, and is majorly achieved by interfacing PACS with RIS and then onto HIS, via a health standard called HL7. More on HL7 in a separate blog article.
Apart from this, cloud-based PACS providers are undertaking enormous efforts to realise 3DMPR (a calculation intensive feature) in a web-setting. There are exciting possibilities for AI’s infusion in radiology as doctors increasingly turn to robust and accurate speech-to-text transcription tools to save their time and expedite patient care.
Where does Nandico fit-in?
So, where do we fit in? Nandico is a cloud-based PACS software possessing a zero-footprint viewer, allowing centres all the benefits as mentioned before. Additionally, we offer the fastest loading speed on mobile devices, a clean and intuitive UI, and a transparent pricing plan. Head over to Contact – Nandico to get a free demo now!
The Bottomline
PACS as a disruptive idea has evolved thoroughly over the past four decades and will continue to evolve as AI and technology make their foray into ever-increasing sectors. As radiologists in a constantly shifting world, we encourage you to try out cloud-based PACS and experience a visible impact in your current workflow.