My PACS is Your PACS

Overlapping yet distinct viewing and manipulation requirements could make sharing tricky. So vendors now stress one enterprise solution for these two — and soon all — “ologies,” but serve up specialty-specific tools to accommodate different workflows.
By: 
Kim Phelan
 
August 29, 2006

A blur has occurred in the very place doctors would normally associate with absolute clarity. An overlapping of departmental PACS has occurred, both in how doctors use them on the front end and what the systems actually are on the back end. And whereas radiology and cardiology departments may once have controlled distinct systems for accessing, managing and archiving their own sets of patient images, a trend toward broad enterprise image management is shifting PACS into the IT domain of CIOs and PACS administrators.
The desegregation of radiology and cardiology PACS in today’s hospitals can be understood by turning to American history. No, not the Civil War, but much further back to the Founding Fathers, who devised a concept with which Americans are well acquainted: one nation, many states, each comprised of unique, colorful personalities, preferences and even cultures. Like the political infrastructure those statesmen developed for a fledgling union, makers of the picture archiving and communication systems of today emphasize a one-enterprise approach that is equipped to handle the particular, individual requirements of not just the radiology and cardiology departments, but also the many other “ologies” within the hospital enterprise community.
Originating in Radiology, PACS were then retooled to meet the emerging needs of cardiologists, who were blazing a new trail (with very specific training) beyond where, in some cases, traditional radiologists were prepared to go. But sustaining two disparate systems is inefficient, manufacturer sources say, and the theme that dominates the PACS market today — as vendors reach out not only to the individual departments but also address turf-neutral CIOs and PACS administrators — is that one solution with separate tool sets and workstations is not only the wave of the future, but is most certainly the answer for present-day image integration with the EHR.
“There is definitely an advantage to having one single platform,” said Richard Taylor, national sales director for ScImage. “The different departments do have different workflow requirements that need different imaging tools and different kinds of views, but from an IT perspective, [one solution allows you] one application that is handling diagnostic imaging, one link to the EMR and HIS, so you are not managing multiple interfaces with multiple departments.
“Just as there are clinical advantages when you have one electronic medical record for the patient throughout the whole hospital, having one diagnostic imaging system for the entire hospital is also very beneficial.”
Compartmentalizing PACS is, indeed, passé, agrees Rik Primo at Siemens Medical USA.
“A PACS repository that holds or is capable of holding all types of imaging data is a safe and future-oriented strategy,” Primo said. “Separate data-islands for each of the imaging specialties is obsolete. PACS will not only have to hold imaging data from radiology and cardiology, but also pathology, ophthalmology, endoscopy and all other ‘ologies’ that are required for state-of-the-art delivery of cost effective and high-quality healthcare.”

Different Yet Alike
The workflow of cardiologists is undeniably different from that of radiologists, which is why PACS vendors offer separate tools and workstations for each group. Cardiologists are patient-centric, and their workflow is driven around their direct involvement with patient care.
“Cardiology has greater emphasis on intervention and chronic disease management,” said Allen Scales, vice president, Corporate Strategy at Emageon. “There is more emphasis on creating a longitudinal patient record consisting of discrete data as well as multimodality images. Key data such as blood pressure and cholesterol levels must be continuously monitored and controlled through the use of drugs. [And] other key measurements such as ejection fraction and heart wall thickness must also be tracked over time.
“As such, there is greater emphasis on clinical structured reporting through national databases such as the ACC-NCDR.”
The workflow paradigm for radiologists, on the other hand, is more study-centric, with an emphasis on efficiency and productivity as they generate a report for a referring physician as quickly as possible, sources agree.
How cardiologists and radiologists may use the PACS can be similar, though invariably each will require different tools to accomplish their tasks based on their unique workflow priorities. Their need for viewing as well as manipulating static and dynamic images is an example of the intertwining of radiology and cardiology PACS. Moving images are imperative for the cardiologist — assessments of the heart’s motion, wall motion and ejection fraction are among the basics for cardiac diagnostics. And, Primo points out, cardiologists often follow an integrated workflow cycle, where the imaging exam, diagnosis and therapy are performed during the same cath lab procedure.
“Angioplasty is often performed immediately during the angiographic procedure, and a stent could be inserted during the exam to keep the artery open and to widen the lumen,” Primo explained. “The effectiveness of the stent on the arterial blood flow is then assessed by viewing the study and by using the image processing and quantification tools on the modality or workstation.
“Further,” he continued, “the cardiologist will often use a wide variety of various diagnostic modalities to come to a diagnosis: DR/CR, MR, CT, NM, PET, ECG, hemodynamic measurements and more. The results of all these modalities should be accessible at the cardiologist’s workplace, preferably from one workstation.”
But the radiologist requires moving images, as well — CT angiography, MR angiography and MR functional analysis, for example, has made motion an important dimension of their image interpretation.
Yet how they each make use of the dynamic, cine images accounts for the distinct tools that vendors provide to the separate speciality physicians.
“The difference is in the image manipulation tools,” said Joe Darr, global segment manager, Centricity Cardiology at GE Healthcare Integrated IT Solutions. “In cardiology, they need tools that can measure things like stenosis analysis of a coronary artery. And they’ve got tools that help them measure ejection fraction rate. There are analysis tools that are specific to the practice of cardiology versus the radiologist, who would not be interested in those types of tools.”
Crossover in tools and their application does occur in one key place, says Jonathan Elion, M.D., chief medical officer of Agfa and a cofounder of Heartlab.
“Requirements have achieved complete overlap in the handling of multislice CT studies of the heart,” he said. “There are identical needs for 3-D reconstruction and interaction with the display.”
A key differential between cardiologists’ and radiologists’ use of PACS is the need for real-time viewing.
“A cardiologist in the cath lab who is doing a study wants to immediately be able to review those images when he is done, and he wants to create his report as well,” said Bob Baumgartner, BSN, senior product manager, Cardiology, at McKesson. “He needs to to send those images from the X-ray unit over to our PACS unit in real time throughout the procedure, acquire them and register them on PACS, so as soon as he takes his gloves off he can go over and start reviewing them.
“We also have a lot of facilities where they want real-time consultations,” Baumgartner continued. “For example, there may be a physician in the cath lab performing a diagnostic catheterization. He sees there is a lesion here but he is not quite sure if it is treatable by intervention or by surgery. So he might call his partner at the office, who is an interventionalist, and have him go to the Web —  the cardiologist in office goes to the Web client and can pull that patient up in real time and say, while the patient is still on the table, ‘We can treat that interventionally, and I can do it in a few minutes; keep him on the table and I’ll be right over.’“

Single PACS Solution and the EHR
As the picture of  PACS usage and their departmentally-tailored tools fades in and out of focus, one thing that remains in sharp resolution is the fact that a single, enterprise PACS solution is central to realizing hospital-wide efficiency and easier integration with the EHR.
“Imaging really is a big piece if not a driver of the EHR,” Baumgartner said.
Dual systems for radiology and cardiology feeding into the EHR create duplication and extra layers of interfacing — all of which go away when imaging is treated as one unit, regardless of the department from which it originated.
“In the end, you have a study and a report in this PACS infrastructure regardless of whether it came from radiology or cardiology,” said Darr. “There is a common format — we simplify things with a simpler architecture, simpler interfaces and one place that you go to for patient information.”
To this Primo adds: “This consolidated, multispecialty, one-repository [PACS] strategy will facilitate the integration of image information in the electronic medical record. When a healthcare provider is retrieving patient information in the EMR, and the EMR can just query one repository to have ubiquitous access to all imaging information, healthcare providers will have access to all relevant patient information in one simple move.”

Sidebar

Majority Rules: Web Access to PACSand Why Macs are Left Out PACS manufacturers across the board offer Web accessibility of PACS images from a remote location — but universal access from any computer is not the reality doctors encounter when they put this claim to the test. At least not when they’re using a Macintosh computer. The majority of doctors use Windows-based PCs, vendors contend, and therefore they have built their systems to be viewed via Internet Explorer (IE); to validate against Mac browsers such as Netscape and Firefox would be not only a time-consuming undertaking, but a very costly one as well. A few manufacturing sources contributed additional insights: Rik Primo, Siemens “Depending on the implementation idiosyncrasies of the Web viewer, we can distinguish between thin and thick clients. Thick clients have often better and more functionality than the thin clients, but require more effort to install on the Web-enabled client PCs. Thin clients are easier to manage from an IT perspective, and are often self-installing. Thin clients sometimes lack the required extensive functionality for measurements. It all depends on for what use the Web viewer will be deployed. Technologies for thin clients can also be hardware/software specific. Some technologies such as the JAVA programming language are more universal and support a wide variety of makes/models of PCs, while other implementations (such as Active X) run only on Microsoft platforms. When choosing a Web viewing solution, one should consider all these aspects. In some cases one can choose a thick client for the more intensive specialty users, while a thin client is preferred for the referring physician, and run both applications from the same PACS server. At Siemens, we support both options.” Bob Baumgartner, McKesson “Firefox is very nice; Netscape is OK — Mac is really nice, and Mac uses Netscape. But the problem is that it is not pervasive enough. If you had 40 percent of the population using Netscape, we would work against it, but there is probably less than 20 percent, and maybe closer to 10 percent. Since the overwhelming majority of the marketplace is IE, that’s what we are going to use. I will say Mac does imaging much better than IE, but the general marketplace is IE. Once you add a second browser, you now effectively quadruple the work you need to do to validate it.” Richard Taylor, ScImage We rely on Windows-based browsers. We don't support the Macintosh with our viewing tool, but you can look up some basic information over a browser access with a Mac. What we and most other vendors do in terms of viewing tools for images over the Web is we actually will automatically download the viewing program to the remote computer, kind of like what happens when you go to read Adobe PDF files the first time. It downloads the PDF viewer. The same thing happens with our viewing tools. The first time you click on a static image set to look at it over the Internet, it will download the viewing program to your local computer. It automatically delivers that viewer program as well as the data. Subsequently, when they look at images [in future], they don't have to re-download the viewing program — it's already there.

The content of this field is kept private and will not be shown publicly.
By submitting this form, you accept the Mollom privacy policy.