PACS has evolved over the past 35 years, and the next decade will be no different. The next generation of PACS technology will be driven by trends such as the expansion of enterprise imaging and the critical need to improve radiology workflow. Artificial intelligence (AI) also will have an impact.
PACS has indeed come a long way. I was involved with one of the very first PACS networks -- if you can call it that -- in the mid-1980s that sent CT images from three hospitals in Lansing, MI, to a central reading station at Michigan State University. That was before there were communication standards, but with the help of university scientists we developed gateways that sent images over the commercial city cable broadband system.
Herman Oosterwijk of OTech.In the early 1990s, the development of the DICOM standard became a major driver for PACS. After focusing initially on image communication, DICOM was extended with workflow capability and the grayscale standard display function to provide consistent presentation of images. This provided the framework at the beginning of the 21st century that enabled most institutions to implement their first generation of PACS.
Over the past five years, PACS has become a commodity. Very few hospitals still issue a custom request for proposal (RFP) for these systems, unless it is for a major deployment that includes several hospitals or if it is a requirement to show neutrality in the vendor selection, such as for a U.S. Department of Veterans Affairs (VA) or Department of Defense (DOD) hospital.
Changing architecture
PACS architecture also has changed during this period. There are basically two forces that are pulling the conventional PACS core apart: first, horizontally across an enterprise, and second, vertically within radiology itself.
We'll address the horizontal direction first. PACS is used beyond radiology to include more specialties, starting with cardiology and extending to dentistry, ophthalmology, oncology, surgery, and other departments. Imaging informaticists in hospitals seem to find a new source of images almost every day, such as photos of wounds in an emergency room, videos that record a patient's gait after back surgery, speech pathology, and many more.
In addition, point-of-care (POC) ultrasound is becoming so affordable -- $2,000 probes are now available that you can attach to your phone -- that the modality has the potential to become as common as a stethoscope for physicians.
Last, but not least, digital pathology is about to be introduced, creating another source of images. Digital pathology is still hampered by the fact that just a single digital pathology system has U.S. Food and Drug Administration (FDA) clearance, but it's just a matter of time before more will follow. Therefore, PACS is evolving from its initial radiology focus to become a true enterprise imaging solution.
Instead of upscaling the radiology-based PACS core to include these different specialties, the need to eliminate lengthy and costly migrations between different PACS vendors when upgrading to a new version has led the industry to vendor-neutral archives (VNAs). The VNA quickly has become the main repository for all these images, reducing the function of the traditional PACS to providing optimized workflow, viewing, and temporary archiving -- maybe up to six months -- for specialties such as radiology.
Using a VNA has become the first step in "deconstructing" the traditional PACS, a trend that is continuing with zero-footprint viewers that can be used instead of conventional PACS viewers. There are examples of institutions that have built an enterprise PACS using a VNA from vendor A, viewers from vendor B, a workflow manager to provide worklists from vendor C, and routing and prefetching capability from vendor D. The VA Midwest Health Care Network (VISN23) is a good example of that, covering 11 hospitals in five states.
Changes in workflow
The second force that pulls the PACS core apart is in the vertical direction -- the workflow. Traditionally, PACS workstations were purely "PACS-driven," meaning that the worklist for the radiologist was created by a PACS workflow manager. Over the past 10 years or so, however, there has been a trend to become "RIS-driven," with the advantage that all of the information in the RIS, such as requisitions and reports, is easily available.
In this model, the RIS is more or less in the driver's seat and calls upon the PACS to display relevant images. However, as over the past few years every hospital has been installing and/or upgrading an electronic medical record (EMR) system, the EMR portal has become the primary entry point for physicians and also specialists, such as the radiologist.
Consequently, most hospitals are starting to let go of their RIS and replace it with the EMR-RIS, and the EMR-driven worklist is starting to evolve. It makes a lot of sense for radiologists to have a single sign-on to all of the clinical information -- including patient history, labs, etc. -- as well as to access the images.
One of the top complaints that users voice about their PACS is its workflow. This is understandable, as there is pressure to do more for less reimbursement while the volume of data is increasing by leaps and bounds.
One example is in breast imaging. Digital mammography used to have four views. However, digital breast tomosynthesis is becoming the standard of care and creates 30 to 40 images that take longer to be viewed. Furthermore, CT studies have grown from hundreds of images to thousands, and new MR sequences provide alternate series to be viewed.
It also is not uncommon for a radiologist to support multiple sites, each having its own PACS system and potentially requiring a different login, viewer, and workflow. There is a big need for efficiency and higher throughput.
This is where AI might be of help. There is a lot of anxiety about AI and how it might replace radiologists by making a diagnosis, which will still be a while. But in the meantime, AI could be really helpful with the mundane task of optimizing and automating the workflow. Imagine self-learning hanging protocols, prioritizing cases which should be looked at first, and other AI capabilities that increase human efficiency.
Non-DICOM data
PACS is mostly focused on imaging, but there are other clinical datasets that need to be managed as well. These include radiology reports, notes, measurements, and, in cardiology, electrocardiograms (ECGs) and electrophysiology data. Some modalities create charts that are typically stored as PDFs, and there are also non-DICOM images such as JPEGs and MPEGs. There are different solutions to deal with the non-image data.
Some of this is stored in the PACS, either in a DICOM-ized format or in its native format. In the case of a non-DICOM format, the system will need to manage the metadata, which is standardized as part of the Integrating the Healthcare Enterprise (IHE) Cross-Enterprise Document Sharing (XDS) interoperability standard.
There are different approaches to deal with these non-DICOM objects, and it's not obvious what to do. The first option is to archive them on the enterprise PACS. Some institutions have done this, but it isn't common yet. When talking to VNA vendors, almost all of them support non-image storage with XDS metadata, but very few installations have taken advantage of this.
The second option is to store them in the EMR. This has also not garnered a lot of supporters.
The third option, which I think is the best, is to use a separate document management system that can be linked to from the EMR portal. The new HL7 Fast Healthcare Interoperability Resources (FHIR) standard makes it very easy to link to these documents, as it uses a standard web-based protocol and a simple uniform resource locator (URL) to get access to these non-image objects. I have seen this used very successfully at the Mayo Clinic, where the diagnostic reports are stored at the document management system that's accessed using a FHIR interface.
Pain points
One of the pain points healthcare providers face when implementing an enterprise image management solution is the workflow for nonscheduled imaging, or "encounter-based" imaging. In a scheduled workflow, an order is placed and either converted from its native HL7 format to a DICOM worklist or used in its native form to create the metadata header with patient demographics, study information, and anything else needed to manage these -- especially the accession number that matches the study with the report and requisition.
In the case of encounter-based imaging, there is no existing order, so these will have to be created on the fly, after the fact, or via a combination of these workflows. It is not uncommon to have different workflows for each department. This is an area where there is still a lot of opportunity for improvement and standardization.
I am somewhat disappointed by the fact that the IHE has not tackled this issue by defining recommended workflows, but it may be that this is still too hard to define, or there is simply not enough consensus for a common standard. The only applications addressed so far by IHE are how to do web-based image capture, such as a physician may do on a mobile device in an ER, and POC ultrasound.
In conclusion, the next-generation PACS will continue to expand and include more specialties; it will deconstruct more and will be driven by the EMR. There are still challenges with the unscheduled workflows, and AI will continue to impact efficiency and improve clinical outcomes.
Herman Oosterwijk is a healthcare imaging and IT trainer/consultant on PACS, DICOM, IHE HL7, and FHIR. He can be reached through his website, www.otechimg.com, where you can also find information about upcoming training and online education on these topics.
The comments and observations expressed are those of the author and do not necessarily reflect the opinions of AuntMinnie.com.
