When PACS and EMRs Converge

14 March 2010 (Last Updated March 14th, 2010 18:30)

As the worlds of PACS and EMRs evolve and converge, medical imaging teams must choose the best systems. David Mendelson, co-chair of IHE International and a member of the Healthcare Information and Management Systems Society (HIMSS), investigates the options.

When PACS and EMRs Converge

Picture archiving and communications systems (PACS) and radiology information systems (RIS) have matured and represent a robust mechanism for the storage and distribution of imaging examinations and reports. These systems are generally optimised for the workflow of the local radiology department and often provide solutions for access from outside a department.

While these solutions have been built from a radiology-centric workflow perspective, the better products often embed elegant solutions to extend services outside the radiology department. Today as the electronic medical record (EMR) undergoes rapid refinement and deployment we must address the issue of what is the best means to transparently incorporate imaging data in a cost effective and efficient manner.

In parallel, the need to archive and display non radiologic medical images is rapidly expanding. What strategies should small and large medical enterprises consider to make medical images available to healthcare providers?

One approach to analysing the issue and understanding the models that might work in different settings is to first state the use case: many physicians, from different specialties, require quick, easy access to a variety of images and results in a centralised environment, the EMR. This use case is much broader than the one facing the world of radiology a little over ten years ago. Then, the challenge was simply to provide the images to the radiologist. All other users were expected to visit the radiology department, as they did in the era of film, to view their patient's exams.

"Radiology was the first domain to adapt PACS and digital services as a normal part of its workflow."

The next step in the evolution of image availability was to provide PACS access, usually limited, outside the radiology department, and to simultaneously provide a printed copy of an exam (on film or paper) to those needing repeated access external to the radiology department.

Within a short time other means of distributing exams arose. Film was expensive and cumbersome. Local networks enabled image distribution via the deployment of the PACS client on workstations throughout an institution. Soon web viewers came on the scene, enabling easy and broad image distribution, on a standards-based platform. There was an initial trade-off: most web viewers successfully showed the basic image set, but offered limited functionality in the way of image manipulation and hanging protocols. This has started to change with web-based workstations now being common.

Today there are several models of radiology image archiving and distribution that may provide a reasonable solution depending upon your environment and financial resources. We will examine each in turn.

Model one: the radiology team owns and operates the entire PACS network

This model is often favoured by radiology departments, because more than ever the ability to read a large volume of examinations in the shortest time is tied to financial success. The major advantage is that the department maintains full control of all aspects of the PACS, including the archive, the network, and the workstation. All investment and service is targeted at moving the radiology images and reports in line with the departmental workflow.

A dedicated staff can often provide the quickest service when parts of the system fail. There is no help desk queue related to other activities in the enterprise. The perceived higher costs of this solution may be counterbalanced by revenue lost by downtime and delays encountered in the solutions to be described below.

What is the downside? This is perhaps the most expensive alternative. To run and maintain the IT infrastructure requires a dedicated staff, knowledgeable about networks and storage, and pieces of the infrastructure may be underutilised.

"PACS have been used around the world now for some time with varying degrees of success."

Today, there would seem to be little reason to maintain a proprietary network, solely for the use of an imaging department. The PACS network is the same infrastructure used for healthcare in general; albeit one that requires the greatest bandwidth. When reservered for imaging only there is generally underutilisation of this infrastructure. One is paying a premium for bandwidth employed in limited bursts.

Other costs and functionality need to be considered. Distribution outside the radiology department can be solved in a variety of ways. Many EMRs employ either an API or a web-based hyperlink into a PACS web viewer. Today it is customary to maintain a secondary business continuity and disaster recovery archive.

The robustness and ease of access to these redundant solutions vary with the financial investment. There is an economy of scale that is lost when these solutions are provided in an isolated environment. This is not to say that it is not a viable solution, but over the next few years it may increasingly become the most expensive one.

Model two: the IT team owns and operates the PACS

A new model is where PACS is a service to the radiology department. As far as the radiology department is concerned, one or two applications, usually an RIS and PACS, are running on workstations supported by IT. The application is the only concern of the radiology department because IT has garnered all responsibility for the infrastructure.

The archive could be employed for radiology only but more often would be part of a larger archive housing all kinds of data. Imaging data can be partitioned off from other kinds of data if necessary. IT hosts all the servers and the PACS is operated over the standard hospital network. All infrastructure support arises with the enterprise IT department and system administration can be run by either IT or Radiology.

In principle the advantage of this solution is that most of the infrastructure to support PACS is the same as that utilised for all other IT services. The same IT personnel that support servers, networking, and storage can extend this skill set to PACS. The support specific to the application may sit within the radiology department or IT, depending on local variables. This solution leverages economies of scale. Its success is in line with the overall level of service that the IT department provides to the enterprise on the whole.

In addition this model potentially provides the easiest route towards integration of PACS and exposure of images into the EMR. Presuming that IT owns the image archive, the IT department has the ultimate flexibility in constructing means of sharing those images with any application. Hence, if an EMR has a DICOM viewer, or has any inbuilt preferred means of viewing images, IT is well positioned to provide direct image access. Image viewing becomes a service. In an environment incorporating a service-oriented architecture (SOA) different services can be built as applications for different departments, all using the image archive application as the image repository to which calls are made.

"As well as helping to implement systems around the world, PACS increase efficiency throughout radiology departments."

Potential problems reside in two areas. First, the generic knowledge of the IT personnel may not be sufficient for an in-depth understanding of problems specific to PACS. Again, a sophisticated IT department may provide extra training to selected staff members to address this issue. Secondly, service for problems is now in line with that provided by IT to the entire enterprise. On one hand this may be beneficial in that support may be extended across a larger number of employees. On the other hand support for the radiology department is now part of a larger organisation, and may not receive the prioritisation it would get were radiology to handle this on its own. A radiologist unable to read exams, waiting for repair on a down workstation, is a costly idle resource.

Model three: hybrid model – PACS as a shared service

Models one and two represent extremes based on idealised assumptions. The first model assumes that a radiology department has unlimited resources and the luxury of fully governing itself.

The second model assumes that an IT department, also having unlimited resources, is in a position to develop and continually support the specialised knowledge pertinent to the radiology domain, beyond what are regarded as common IT solutions.

Hence the requirement for a third model, which may represent a reasonable compromise: a shared service. This requires getting over some political barriers, but where this can be achieved it can be a very effective model. Let each group take care of what it knows best and through robust communication ensure effective support for all end-users requiring images.

The IT department may provide the knowledge and support for the infrastructure, which is quickly becoming generic and identical to that of the overall institution. The unique component of a radiology solution has become the application itself, and its relationship to some relatively customised hardware. For instance, a radiology workstation often requires multiple high-end monitors and the associated video cards. These may require special calibration. For these requirements the radiology department may maintain some IT personnel who have some technical expertise in addition to system administration knowledge.

Overall the hybrid solution may represent the best balance. It should yield significant cost savings, with a skilled IT team supporting most of the infrastructure, as part of the overall institutional support, while a scaled-down radiology IT team handles the functionality unique to the department and provides the "instantaneous gratification" for support, beyond that normally expected from a typical help desk.

Other imaging services

Radiology was the first domain to adapt PACS and digital services as a normal part of its workflow. Other specialties that provide radiological imaging services, particularly cardiology and orthopedics, have recently adopted similar solutions. It is not surprising that other image-dependent specialties wish to attain the same benefits and efficiencies appreciated by these first adopters.

Ophthalmology and pathology would appear to be strong candidates to leverage the benefits of PACS. However, they each have some unique characteristics that require tailoring of a solution to their department workflow. Both deal with colour images and ophthalmology also needs to archive graphical data. Pathology needs to capture images ranging from electron microscopy to gross specimens.

"The unique component of a radiology solution has become the application itself."

A particular problem in pathology is the issue of what images to select. Traditional pathology involves the pathologist viewing a specimen mounted on a slide (or the equivalent), identifying a field of interest, tagging it for reference in some manner, but always having the original tissue available for re-examination. This differs from the traditional radiological image in its simplest sense, where the entire image is ultimately the object that is preserved. I have over-simplified this in the case of cross-sectional imaging, where there is an ongoing debate regarding what needs to be archived for CT and MR exams, both of which may now include thousands of images. The pathology domain needs to work through this problem to determine the point of image selection, who will select the images for preservation in a PACS and whether the PACS is a front-line service or merely an archive after tissue has been evaluated.

Pathology and ophthalmology commonly employ colour images and hence images are of significantly greater size than the gray scale images of radiology. This increases the archive requirement, at least per image stored, and changes the bandwidth issues in terms of moving images.

Other domains and the images unique to them need to be considered as well. EKGs and other waveforms are image types that many clinicians wish to have easily available. Endoscopic and bronchoscopic images are often archived in proprietary systems. A simple photograph may have tremendous value in certain disciplines.

All of the above issues have potential solutions but they need to be solved in the context of the workflows in each specialty.There needs to be a set of standards that vendors can deploy to facilitate interoperability. There are DICOM standards for ophthalmology and IHE profiles. There is DICOM WG-26 developing proposals for pathology. Likewise, all these image types ultimately need to be shared with a broad spectrum of individuals providing care to the patient. As solutions develop, ways of incorporating them into the EMR need to be considered.

The EMR as an image archive

This brings us to one further consideration: can the EMR host an image archive? Certainly many EMR products are incorporating the ability to hold images as a primary archive. Generally this capability is designed to accommodate a photograph or scanned document. Thus in a limited fashion EMRs can archive images and make them easily available for clinical use. In fact from the point of view of a clinician this may in fact represent the best integration of image data within the context of the entire patient record.

However from the perspective of specialty departments, such as radiology, this is generally not a feasible solution. In the preceding models the image archive is robustly integrated into a workflow model. This is difficult to achieve in the EMR product, where the database design is tailored to the workflow of the clinician.

One might argue that the EMR might contain a mirror of the primary image archive, and be employed directly by the EMR itself for image viewing. This might solve a business continuity and disaster recovery need for an institution. Why not have the EMR fulfill this role as well as make images easily accessible within the product? The only additional requirement, would be to identify one copy of the image as the "gold" copy and ensure that the second copy is always kept synchronised.

The EMR as an integration point

Lastly, let us not forget that the EMR is the evolution of the entire medical record. It is intended as the sole integration point of numerous types of medical data, with the hope that this integration permits a cohesive view of the patient. This easy availability of all kinds of information enhances care in that the clinician need not presuppose what he will need to know.

"The better products often embed elegant solutions to extend services outside the radiology department."

As questions arise, the information required to make decisions and move forward will always be at the fingertips of those providing care. There will be no need to go hunting in a variety of systems, some not easily available, perhaps due to their remote physical location or simply the need to have a log-on and password for a system one rarely uses. As computer-assisted diagnosis and decision support tools evolve it is important that such systems can leverage complete information. Image data is simply one more source of data that needs to be incorporated into these tools.

Not to be lost in this analysis is the benefit of the EMR to the specialty physician, usually the radiologist and pathologist. The reality today is that these physicians are expected to provide expert opinions in a void of supporting information. The value of their analysis is immensely improved with context and detail available at the time of interpretation.

We may soon see the radiologist desktop incorporate PACS functionality with the EMR running alongside with context sensitive information passed between the two at the desktop. This would greatly improve the provision of clinical information to the specialist.

Today most EMR products provide limited customisation for the end-user. All nurses are provided with a standard "nursing" view. Likewise, all physicians are provided the same view no matter their specialty. As the EMR evolves we may see custom views enabled. At some point the functionality of specialty workstations such as PACS might be incorporated into a single EMR product, but not yet. The functional equivalent in an SOA world may be that the EMR evolves into a medical "database" with all kinds of data from clinician notes to images. Custom views of the data are applications that make calls to the database and update it with information provided by the end-user, from clerical staff to physician specialist.

Conclusion

We have reviewed the evolution of the workflow behind digital healthcare information. Realistically any of the three models described are viable and can support a departmental workflow as well as provide the image to general clinicians through the EMR.

We have reviewed the price, support and performance issues associated with each of the choices. As SOA becomes a reality in healthcare we will probably see a migration to the two models where IT is involved to a significant degree, meaning the IT department's expertise with regard to networking and storage is leveraged. Applications will be put in place that can access the image data through the SOA and be tailored to the needs of the end-user. Today, given that SOA is not widespread in healthcare, we can accomplish a similar model by using custom APIs, when an enterprise has decided that IT can best support the archive.