Technology

RSNA 2017: PACS Reconstruction

dondennison Healthcare IT , , , , , , , ,

RSNA 2017 Logo

“All the king’s horses and all the king’s men…”

Deconstructing a PACS into discrete, enterprise-scale components seems to be all the rage for many organizations. But, like many things in life, taking something apart is often far easier than putting the pieces back together (and getting something that works).

At this year’s RSNA meeting, I will chair a session on PACS Reconstruction (RCC24) on Mon 27-Nov-2017 from 2:30 to 4:00 pm CT that will focus on the challenges and opportunities of building an integrated enterprise-wide imaging solution for diagnostic review and clinical access.

Following my introduction of core concepts, we will hear from Charlene Tomaselli, Director of Medical Imaging IT at Johns Hopkins and Bob Coleman, Senior Director of Enterprise Imaging Informatics at MaineHealth on their progress and vision to providing an integrated imaging solution for their enterprises.

We will have a panel Q&A with the audience to share lessons learned and discuss how to best prepare for changes.

Enterprise PACS vs. Vendor Neutral Archive (VNA)

dondennison Healthcare IT , , , , , ,

I recently contributed an article to HealthCareBusiness that explored the scenarios whereby the use of an Enterprise PACS—defined as a system serving multiple organizations and facilities across an enterprise—or the use of a VNA may be the right approach for an organization seeking to consolidate their image archive and provide a longitudinal patient imaging record. It also covers some scenarios where both may be required.

To some vendors, this can be an ideological debate. It can also lead to discussions about the definition of what is “vendor-neutral” or not.

What is important is understanding what problems you are trying to solve, what requirements exist for the overall solution, what benefits you expect (and a plan to measure them), and having a feasible plan to get there.

Medical Imaging Informatics and Teleradiology (MIIT) 2017

dondennison Healthcare IT , , , , , ,

The 12th Annual Medical Imaging Informatics and Teleradiology (MIIT) meeting will be held on Friday April 28, 2017 at Liuna Station in Hamilton, Ontario, Canada. This year’s theme is Enterprising Imaging and AI: Welcome to the Future and the program features many fascinating talks by thought leaders, including Drs. Eliot Siegel and Chris Roth.

MIIT 2017 has an all new interactive website and meeting app for increased attendee participation.

Genady and I will each be giving a talk.

Enterprise vs. Diagnostic: Image Viewers Converging?

don-headshot-round

Don K Dennison

As web technologies evolve, the gap between Enterprise Viewers used primarily for accessing images as part of a patient’s electronic medical record and PACS Viewers used for primary diagnostic review is rapidly closing. But how close are they, really? This talk will explore the feasibility of Radiologists using a web viewer instead of a PACS for reading.

Managing Imaging in an EMR Centric Era
genady-headshot-round

Genady Knizhnik

As health systems converge on a common electronic medical record (EMR) system and longitudinal patient record, new requirements and expectations are placed on imaging records and the systems than manage them. This talk will explore the impact that the implementation of a modern EMR has on patient and procedure information within PACS, VNA, and other imaging IT systems.

Program and Registration

See the complete program here. Register to attend here.

Meeting Sponsorship Opportunities

Interested in sponsoring MIIT 2017? Read about the available sponsor packages here, or register as a sponsor here.

Dealing with Multiple Terminology Domains in a Consolidated Enterprise – Part 2

genadyknizhnik Radiology , , , , , , ,

In my previous post, Dealing with Multiple Terminology Domains in a Consolidated Enterprise, I introduced a typical challenge that many imaging projects face today.

In this post, I will describe three common use cases where the problem of multiple terminology domains manifests.

Single PACS, Multiple RIS

Often, rapidly growing health systems aim to consolidate imaging informatics solutions across their facilities. Replacement of multiple PACS with one such system, while keeping separate RIS systems in place is not uncommon. The reason behind this dichotomy is that a RIS is much more ingrained into the local Radiology department’s operational and clinical workflows than a PACS, making its replacement complex and impactful on many stakeholders.

The following diagram illustrates this scenario.

term-pacs

In such a deployment, the consolidated PACS is responsible for dealing with multiple ordering systems that use individual procedure terminologies. It also maintains patients’ longitudinal imaging record, which will include different values in the DICOM headers to describe the same procedure types.

Multiple RIS/PACS, Shared VNA

Health systems that seek to benefit from IT infrastructure consolidation, as well as a single Imaging Record Management, Archive, Access, and Sharing application, often opt to procure and deploy a shared VNA system across their facilities. By keeping their RIS/PACS systems in place they can rapidly deliver clinical and operational benefits with minimal disruption to the existing workflows. This approach allows individual facilities to stay fairly independent in their imaging informatics system and process decision making.

The following diagram illustrates this scenario.

term-vna

In this deployment, the shared VNA typically maps or normalizes procedure terminologies in the DICOM header of the studies that are served to the individual PACS systems as part of the relevant prior pre-/push-fetch workflows.

Single PACS, Single RIS

An increasingly common scenario is when health systems include a RIS consolidation project within their EMR consolidation strategy, while PACS consolidation happens in parallel. This approach results in a single master set of orderable procedures that is used by all participating facilities. The challenge arises from the fact that historic imaging records maintain, in the DICOM data, procedure information using historic terminology values that predate consolidation and can include known values (from the latest RIS) or some potentially unknown value (previous RIS systems for the institutions that replaced their RIS system at least once and did not replace the values with one used by the new RIS).

The following diagram illustrates this scenario.

term-rispng

In these deployments, the consolidated PACS is responsible for dealing with new common and fragmented historic procedure terminologies.

In the next post, I will describe how PACS and VNA vendors deal with this challenge.

Dealing with Multiple Terminology Domains in a Consolidated Enterprise

genadyknizhnik Healthcare IT, Radiology , , , , , , ,

As the number of the PACS consolidation projects grow, I think it is important to explore some of the informatics concepts that need to be addressed to maximize the value of a consolidated PACS’ clinical functionality.

As mentioned in my recent MIIT talk, there are operational, financial and clinical goals that drive PACS consolidation projects. One of those reasons is to enable multi-facility diagnostic reading workflow: acquire anywhere and read anywhere in the enterprise.

One of the key informatics prerequisites of a successful PACS consolidation project is dealing with Patient Identities in a Consolidated Enterprise to establish patients’ longitudinal imaging record. Once that fundamental challenge is addressed, dealing with the normalization or mapping of the exam terminologies used by different RIS systems across the consolidated enterprise is the next critical informatics area to tackle. Often, PACS consolidation projects do not include the unification of the facility RIS, which forces the PACS to deal with multiple terminology domains.

In this series of the blog posts, I will examine this challenge in detail and describe the imaging informatics industry’s current capabilities to deal with it.

The Challenge

First of all, let’s define the problem and why it is important.

The anatomical and procedural information for a radiology exam is used by the PACS to primarily: 1) determine relevancy across patients’ historic studies; and 2) establish the correct display protocol for the PACS Workstation. As different ordering systems (EMR/RIS) may use different values to describe the same ordered procedure, the consolidated PACS will have to use a value normalization or mapping method to properly process the information.

The following diagram conceptually illustrates the difference between normalization and mapping methods.

terminology

Mapping

This approach relies on keeping many-to-many translation tables where each term has a corresponding defined value under each terminology domain. This approach is feasible only with a very small number of values and terminology domains.

Normalization

This methodology creates a “canonical” representation of each term and establishes a one-to-one relationship between each value in each terminology domain and the corresponding value under the “canonical” representation. This approach can accommodate a very large number of values and terminologies, as the translation from one terminology to another is always done through the canonical value.

In the next post, I will describe the imaging informatics use-cases that have to deal with this challenge.

VNA and Enterprise Viewer Projects’ ROI

genadyknizhnik Financials , , , , , ,

When I discuss industry trends with colleagues and clients, I find that we periodically touch on the topic of defining and realizing VNA and Enterprise Viewer (EV) projects’ return on investment (ROI). Our industry has made several attempts to develop an ROI calculator, which would typically encompass:

  • the benefits of consolidating IT infrastructure;
  • avoiding the cost of repeat exams due to the availability of a longitudinal patient imaging record;
  • and efficiency gains stemming from the optimized distribution and visualization of medical images.

Often these calculations are tied to a specific project and not easily reused.

During our involvement in various VNA and EV projects, we observed an interesting pattern that can bring an additional perspective on the ROI discussion.

By the end of 2010, the vast majority of U.S. hospitals had installed a PACS solution. The bulk of the deployments took place during the 2005-2010 period, and many of those are still in place, bolstered by many upgrades and technology-refresh cycles since their initial installations. During that period, both the hardware and storage components of a PACS solution were often procured directly from the PACS vendors. This procurement approach allowed the vendors to enjoy significant Service and Maintenance Agreement (SMA) revenues that would cover not only their solution components but also any included third-party hardware and storage.

Since that procurement wave, many things have changed:

  • PACS market maturity resulted in a commoditization of some of its functional areas
  • Hardware and storage costs have significantly dropped
  • Server virtualization became the preferred deployment methodology
  • Procurement of the infrastructure components has been steadily shifting from the Radiology department to the Enterprise/Corporate IT team

Also, PACS market saturation depreciated PACS vendors’ software license sales, resulting in SMA revenues becoming the key contributor to their top line.

All of these changes often created a tension between a hospital’s staff and its PACS vendor because the perceived value of the services delivered under the SMA contracts do not seem to warrant the high dollar cost. Besides tough negotiation tactics, a hospital has few practical tools at its disposal to change this dynamic. This is where well-thought-out VNA and EV projects may become extremely important in changing the negotiation power balance.

The technical and operational benefits of having a VNA take over a PACS Archive, EMR integration and sometimes even workflow components by the VNA and EV solutions are well documented and often result in the hospital’s reduced dependency on the existing PACS vendor.

Consequently, a hospital that implements VNA and EV solutions will be well-suited to renegotiate existing PACS SMA contracts to adequately reflect the provided service. The reduced SMA value can partially offset the cost of VNA and EV projects, thus contributing positively to the ROI calculation. Having said that, without a compelling event, such as an RFP to replace the existing PACS, the incumbent vendor will have little incentive to concede in the SMA renegotiations.

In order to successfully realize the above potential savings, it is important to understand what core functional areas of a PACS can be replaced by a VNA or an EV solution. Consider the following diagram:

ROI-1

Impact on Workflow or External Systems Replacement Complexity Industry Ability to Replace
Long-term Archiving and ILM This functionality is typically not exposed to external systems and has relatively simple orchestration workflows Low: Besides the need to keep the VNA copy of the study in sync with the one cached by the PACS, the archival and retrieval functionality is relatively straight-forward Current state-of-the-art VNA solutions offer proven methodologies to take over this functional area from the PACS
Routing, Pre-fetching and Relevancy This functional area may play an important role in orchestrating a departmental or an enterprise workflow Moderate: Relevancy detection can potentially increase the relative complexity of study routing and pre-fetching, which are typically quite straightforward due to their transactional nature The majority of the leading VNA solutions can adequately deliver this functionality, but their rule-definition flexibility coupled with their ability to express sophisticated relevancy rules (especially across multiple terminology domains), may vary
Acquisition and Quality Control (QC) Workflow Orchestration This functionality has a major impact on the acquisition and reading workflow with a large number of 3rd party systems integrations High: The large number of acquisition modalities will often have different associated configurations. Additionally, in large enterprises QC workflows could be very complex involving both automatic and manual activities. The effort to recreate all QC workflows, which were accumulated over the course of many years could be quite significant The VNA systems’ ability to provide this functionality represents one of the major product differentiation areas among current vendors
Image Distribution and EMR Integration An ability to provide access to images outside of the Radiology department is a critical component of a provider’s single patient record objective Low: The need to provide access to images within multiple applications (e.g. EMR, portal) or stand-alone impose some security and integration challenges. Besides the privacy and security considerations, the rest of the deployment and integration activities are relatively straight forward. Current state-of-the-art EV solutions offer proven methodologies to take over this functional area from PACS

Although this post is primarily focused on SMA-related costs, the reduction of the PACS functional scope will also decrease the corresponding Professional Services expenses.

Working on an Enterprise Imaging project? Leave us a comment with your thoughts, or contact us.

Developing an Enterprise Imaging Strategy—What is the best approach?

genadyknizhnik Healthcare IT, Uncategorized , , , , , , , , , , ,

In my last post, we explored the current state-of-the-art of the Enterprise Imaging (EI) industry. In this post, I will zoom in on storing and managing non-DICOM images and videos. This can be ambiguous and may confuse providers who are trying to procure an EI solution. It also results in different schools of thought among vendors.

Currently, EI content can be stored and managed in one of the following formats:

  • Original object (e.g. jpg) stored in a solution’s database and/or filesystem using the vendor’s API (Application Programming Interface)
  • Original object (e.g. jpg) stored using the IHE Cross-Enterprise Document Sharing (XDS) integration profile in a solution’s XDS Document Repository component
  • Original object (e.g. jpg) stored in a solution’s database and/or filesystem using HL7’s FHIR® Media Content specifications
  • DICOM object stored in a solution’s Image Manager/Archive component; for example, using the IHE Web Image Capture (WIC) integration profile
  • DICOM object stored in a solution’s Image Manager/Archive and XDS Document Repository components using the IHE Cross-Enterprise Document Sharing for Imaging (XDS-I) integration profile

The following diagram depicts the main steps that take place during information capture activity for each method.

storage methods

All of the above methods have corresponding pros and cons, which leads to the current divergence of opinions regarding the best option to use. Having said that, it is clear that, irrespective of the chosen method, there is a need to properly collect and manage patient, administrative and clinical context (aka metadata) for the acquired EI content.

Metadata

Each of the above methods offer different levels of metadata rigidity and extensibility which impact the interoperability:

  • DICOM, FHIR and XDS-I based methods offer a level of certainty for the vendors with respect to what information should be captured and how it should be encoded.
  • XDS takes an approach of developing specific content profiles that address specific types of content; for example, the IHE XDS-SD (Scanned Document) integration profile. At the moment, there is no content profile that is specific to the Enterprise Imaging domain. Additionally, XDS allows the original object to be wrapped in a CDA Document to capture additional metadata in case the specified XDS Document Entry attributes are not sufficient.

Is there one “right” answer?

There are two overarching clinical reasons to capture EI content:

  1. To enrich patients’ clinical record
  2. To provide reliable, authorized access to it across the enterprise (and beyond)

As the following diagram suggests, the way EI content is stored is less important then the flexibility of an EI solution’s “Capture” and “Discovery and Access” components, because it is hidden behind those interfaces.

EI Access

It seems that, currently, there is no single answer for the best EI content format given the informatics complexity of healthcare provider’s enterprises. In order to adapt and compete, vendors will be pressured to support multiple inbound and outbound methods (such as FHIR, DICOM, DICOMWeb, XDS, proprietary APIs, etc.) and only time will tell which approach will become a de-facto standard.

Working on an Enterprise Imaging project? Leave us a comment with your thoughts, or contact us.

Enterprise Imaging Industry State-of-the-Art

genadyknizhnik Healthcare IT , , , , , , , , , , ,

Based on discussions with colleagues and our clients, Enterprise Imaging is becoming an integral part of U.S. Hospital IT Consolidated Clinical Record strategies.

HIMSS-SIIM Enterprise Imaging Workgroup‘s current working definition of Enterprise Imaging is as following:

  • Diagnostic Imaging – Encompassing traditional diagnostic imaging disciplines such as Radiology and Cardiology
  • Procedural Imaging – Including images that are acquired for diagnosis or clinical documentation purposes (such as visible light photos, point-of-care ultrasound)
  • Evidence Imaging – Including images and/or videos that are acquired for clinical documentation purposes (for example, scope videos, computer aided detection)
  • Image-based Clinical Reports – Documentation that includes or entirely consists of images (for example, Pulmonary Functional Test (PFT) report, multi-media pathology report)

Despite the attention from vendors, industry focus, and provider demand, this market space is still in its early stages of development. There are two main reasons: 1) the scope of the problem domain is still being defined; and 2) the vendor community is still working out the best practices and optimal technical approaches.

Moreover, the number of the departments that generate Enterprise Imaging content and that have their own departmental workflows is quite large.

This results in significant confusion on the provider side who are left to navigate a myriad of perspectives expressed by the imaging informatics industry. There are on-going initiatives that are currently working on demystifying the field of Enterprise Imaging. For example, the recent SIIM Webinar delivered by Dr. Towbin from Cincinnati Children’s, provides a very thorough analysis of the problem domain.

In conversations with vendors and providers, we have compiled several observations that might benefit the imaging informatics community.

The Right Approach

In the SIIM 2015 Opening General Session presentation, Don Dennison presented the following slide titled “Enterprise Image Management: Making the Right Choice”

EI

With the various systems in place to manage patient record data, there is often debate as to which enterprise system is best suited to offer Enterprise Imaging services.

At the moment, there is no obvious answer to the question presented by the slide. Besides the technical capabilities of the systems, the provider’s internal IT capabilities, capacity and policies can significantly influence the decision. At some organizations, where the Imaging Informatics Team plays a prominent IT role, the choice could be the VNA, while at others, where the Enterprise IT team takes the lead, the EMR or ECM is often chosen.

The Right Functionality

During RSNA 2015, we conducted a study to identify the state-of-the-art of Enterprise Imaging technology, including methods of acquisition, management, and distribution of non-DICOM images. The following table summarizes our findings.

 

Image / Video Acquisition
Ability to capture from mobile devices The majority of current vendors opted for native applications to provide better user experience and tighter security controls. Still, image capture is the prevailing capability, with video acquisition capabilities lagging behind. Some vendors offer integration with leading EMRs’ mobile applications.
Ability to capture from visible light cameras The ability to manually (i.e. file browse, drag & drop, etc.) upload both videos and images is a commodity. Automatic ingestion, on other hand, varies significantly from vendor to vendor. Most vendors offer proprietary integration frameworks, but their comprehensiveness and real-life integration experience is very different from one to another.
Ability to capture from different scopes Most of the vendors leverage third party hardware devices to integrate with digital or analog video sources real-time.
Acquisition Workflow
Order-based Workflow DICOM Modality Worklist (DMWL) SCU support, as well as the ability to generate or receive order information, are available in most vendor’s applications.
Context-based launch of the capture application is also a well understood and supported functionality.
Many of the vendors mimic an order-based workflow (i.e. create the Accession Number) for the acquisitions that are not scheduled. The main challenge with this approach is to determine the correct method to feed the created information back to the EMR (e.g. often called an “unsolicited result”, which may not be supported at the site).
Encounter-based Workflow Some vendors, originating from the Diagnostic Imaging space, struggle with native Encounter-based workflow support.
On many occasions, departmental visit/encounter information, supplied in HL7 messages from the EMR, is sufficient to build specific acquisition worklists for different service lines.
Scenarios where information services are not available Most of the vendors offer the ability to manually create patient and procedure information. The difference lies in whether all or just a sub-set of capturing methods (e.g. mobile vs. desktop) support that functionality.
Patient identity management Standards-based methods to discover or receive patient information is widely supported, while the support for proprietary methods to connect to patient information sources varies from vendor to vendor.
Ability to Edit Images/Videos
Editing Tools Most of the vendors rely on an installed Windows OS client application to edit (e.g. crop) acquired images or videos as part of the manual upload process (e.g. drag & drop). Selected vendors also allow static image editing only (i.e. no video) during the mobile capture.
Images An ability to associate different types of metadata (including notes) is supported by the majority of the vendors. Also, basic manipulation of the acquired images such as image deletion, markups and annotation, which are stored as overlay objects associated with the acquired images is common.
Only selected vendors are capable of calibrating images on-the-fly by using recognizable objects of known size embedded in the image.
Videos A flexible and comprehensive ability to associate different types of metadata (including notes and keywords) is supported by the majority of the vendors.
Most of the vendors have very limited (if at all) video editing and capturing capabilities and rely on third party providers.
Viewer
Current state The solutions typically consist of the following viewers:

  • Mobile capture
  • Desktop image/video upload
  • Desktop image/video editor
  • Zero-footprint (ZFP) EMR viewer with very limited, if at all, editing capabilities
Privacy and Security
Current state Most of the vendors offer a range of methods to ensure PHI protection such as:

  • Information deletion/encryption from the device
  • Strong Authentication and Authorization methods
  • Auditing
Reporting
Current state The most prevalent approach is to rely on an external system, such as the EMR or specialty-specific reporting application, to create and manage reports.
Record Management
Current state Most of the vendors opt for managing image and videos in their native format, while converting the content on-the-fly for standards-based communication with external systems.

Conclusion

It seems that Enterprise Imaging is going to rapidly evolve and we are eager to see how our clients, and providers in general, will benefit from these changes.

Working on an Enterprise Imaging project? Leave us a comment with your thoughts, or contact us.

Article – MU No More…Meet MACRA, MIPS and APMs

dondennison Policy , , , , , , ,

The death of Meaningful Use (MU) will not be mourned by many physicians.

While the overall program drove adoption of electronic medical record (EMR) systems, which is necessary for information accessibility, the measures required to be reported upon were viewed by many as misguided and not a reflection of the actual practice of medicine.

Also, many of the EMR systems implemented were criticized as being hard to use with limited capabilities to allow information interoperability with other systems.

Regardless of one’s views of MU, CMS is moving on.

With a keen focus on patient outcomes, CMS is looking to new models for reimbursement, such as the Medicare Access and CHIP Reauthorization Act (MACRA) legislation, introduced last year.

CMS is also intent on addressing the lack of interoperable patient record information.

“We’re deadly serious about interoperability. Technology companies that look for ways to practice data blocking in opposition to new regulations will find that it will not be tolerated.”

Andy Slavitt, acting administrator of the Centers for Medicare & Medicaid Services

The MACRA site provides an overview of Merit-Based Incentive Payment System (MIPS) and Alternative Payment Models (APMs), which are sure to be popular acronyms to fill the void created by the decline of the use of MU in discussions.

Here is another article on Slavitt’s comments. And another article by HIMSS.

My previous posts on healthcare payment reform are here, here and here.

Article – First Look at Stage 3: CMS Sticks to Its Guns on APIs, Patient Engagement

dondennison Policy , , , , , , ,

Here is a good summary on what is new in Meaningful Use Stage 3 Rules.

This excerpt caught my eye:

As far as timing goes, CMS said it disagrees that the API functionality cannot be implemented successfully by 2018 “as the technology is already in widespread use in other industries and API functions already exist in the health IT industry.”

All of this should be a boon for the FHIR (Fast Healthcare Interoperability Resources) standard development community and the Argonaut Project, working on API-related standards, as well as for the broader community of mobile app and personal health record developers. With barriers to patient access to their data coming down, patients will finally be able to create their own portals, separate from any health system and share that data with whomever they want.

This is good news for everyone.

If we truly want so solve issues that require access to information where and how we need it, we must provide interoperability. This means not only the data needs to available be in a format that is understood and supported by common applications, it means the method of discovering and accessing that data needs to be understood and supported, as well.

FHIR® (clinical data) is built on the right web technologies and design methods, as is DICOMweb™ (imaging data). With these APIs, we can discover and access the necessary patient information and make it available in any care setting we need.

And these APIs will create the foundation of data liquidity to spark an explosion of innovation of applications—including traditional departmental and enterprise ones, but also web and mobile ones.

Without clearly defined, supported and accessible APIs, we (healthcare) had no hope of achieving the kind of system-wide change required. We have no more excuses now.