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

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.

RSNA 2016

rsna_2016_logo_dates_rgb

In what I believe is my 15th consecutive RSNA, I have a full schedule of business meetings, committee and board meetings, with some time for connecting with friends. In addition to the typical, semi-organized chaos, I am giving two talks.

Hope to see you all in Chicago.

RCC24 – Starting a Health IT Consulting Company

Room: S501ABC
Mon 28-Nov-2016, 2:30 pm to 4:00 pm CT

RC654 – Using IHE Profiles to Plan for Medical Imaging

Room: S504AB
Thu 1-Dec-2016, 8:30 am to 10:00 am CT
chicago-rsna

Dealing with Multiple Terminology Domains in a Consolidated Enterprise

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.

Article: Major Insurance Company will no longer cover Breast Tomosynthesis Exams

Per this article, citing lack of clinical evidence and radiation dose concerns, Cigna will no longer cover Breast Tomosynthesis exams, which generate 3D image sets, as of 15-Feb-2016.

Digital Breast Tomosynthesis (DBT) exams are often praised for their superior ability to provide effective imaging when diagnosing women with dense breasts.

Somewhat of a challenge for IT systems and staff due to the significant size of their data sets compared to the traditional 2D mammogram exams, adoption of DBT modalities has been rapid lately due to the generally accepted diagnostic benefits.

I can’t imagine that this lack of coverage will last.

For those wanting a description of the different between 2D (Mammogram) and 3D (Tomosynthesis) breast imaging, this article provides an overview in plain language.

Here is an RSNA article on the state-of-the-art for Breast Tomosynthesis.

And here is an article on the merits of Breast Tomosynthesis over traditional Mammography for detecting cancer.

And another on reducing recall rates.

Creating Practical Value in Practice (of Radiology)

There is a lot written these days about the shift from volume-based to value-based in Radiology (and other medical specialties).

The thing is: volume is real easy to measure. And what gets measured, gets managed.

So, how do we measure value?

One can measure the time it takes to complete the report, sign it, and make it available to physicians and other members of the care team. Radiology practitioners call this Turnaround Time (or TAT). This is pretty easy to do.

We could try to measure whether the report is correct. In other words, is what the Radiologist concludes actually what is wrong (or not wrong) with the patient? This can be harder to measure, as it may take a lot of work to correlate many different data points, or a lengthy period of time for proof to be found.

There are a couple of activities that Radiologists, and other people working in the department, can do to improve the perceived value of Radiology.

In this article, a number of suggestions are made as to how to increase the visibility of Radiologists, as well as improve relationships and trust among other physicians and even patients.

And this WSJ article focuses on simply improving the clarity of the report by improving the language and writing skills of Radiologist. Seems obvious as to the value this would provide, when you read it, but how many Radiologists routinely attend training on how to communicate better?

While improving how Radiologists interact with the outside world—whether through better interactions or better writing—will help the Radiologist’s career, one would hope that it would also improve care. Better communication certainly couldn’t hurt.

Article – Who is the better radiologist? Hint, it’s not that easy.

I really enjoyed this article. It gets into the specifics of what we could mean by quality of Radiology reading.

I think it gets to the crux of the problem in any domain when quality is desired—a trade off is necessary. It may be cost, or it may be the experience of the user, but it will be somewhere.

Let’s use a similar evaluation in software development.

Coders that are fast are lauded as innovative and bright and creative, until their barely-tested and unscalable application fails in operations, or a security hole results in a data breach. These folks are often called “hackers” (but generally in a positive way).

The more thorough developer is criticized for taking too long and keeping the application in the lab (instead of the “real world”) for too long. They spend significantly more time in the design and testing and documentation areas, so to outsiders, they are slow. Their products take more time (missing some early opportunities seized by hackers), but the applications are much more reliable and supportable in operations. They are professional software developers.

As someone that has managed R&D teams before, you always want both behaviors (and results), but as the article posits, you often cannot have both. You certainly shouldn’t expect to get both.

I often say: Decisions are easy (I decide I want innovation and reliability, and I want it fast), but Choices are hard. I value people that can make choices, and live with them, much more than so called “decision makers”.