IHE Buyers’ Guide Updated for 2017

Interactive IHE Buyers Guide

A new year and another update to the IHE Buyers’ Guide.

This update contains mostly minor changes in the form of some notes regarding some recent or pending updates to IHE integration profiles.

The most notable update is the addition of the Digital Breast Tomosynthesis Extension (DBT Extension) integration profile to the guide for Enterprise Viewer, PACS, and VNA products.

The IHE Buyers’ Guide is a valuable resource when using IHE integration profiles and actors to specify requirements in procurement processes, such as a Request for Proposal (RFP). It does not require you to enter any personal information and is free to use.

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.

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.

What can Enterprise Imaging Learn from Radiology?

Radiology Information Interoperability for Productivity and Quality

In the early days of Radiology, data entry errors by Radiology Technologists (aka Techs) were common. Their attention was on the patient and the operation of the modality, not the clerical task of typing in data, after all. To address this, something called a DICOM Modality Worklist (aka DMWL) was developed and adopted.

Essentially, this took the textual patient and imaging procedure order information entered into the HIS or RIS (i.e. the order placer), and sent it to some system as an HL7 ORM message (an order). The structured patient/order information was then provided to modalities using the DICOM protocol (because this is the language they speak). DMWL could be provided by the RIS or PACS or some form of broker system that spoke both HL7 and DICOM.

This allowed trained clerical workers (or physicians), combined with software that validated the data entered (where it could), to pass the information to the modality workstation where it could be mapped into DICOM objects, without having to ask Techs to enter this info. The productivity and information quality gains were significant.

It is worth noting that the order provides other value than just eliminating duplicate data entry. It represents a work instruction, and it is used in scheduling and billing. Where image acquisition is not scheduled or billed for, orders are typically not created.

Enter Enterprise Imaging

As we enter the era of Enterprise Imaging, there are lots of lessons that we can learn from the solved problems in areas like Radiology.

For example, when capturing a photo in a Wound Care clinic, it has to be associated with the correct patient (obviously), but there is likely other pertinent info that should be captured, such as the anatomical region imaged and any observations by the physician.

In Enterprise Imaging, orders are often not placed. In many areas, the imaging is often not the primary task, but one that used to support clinical work.

If orders are not placed, how can we at least provide the benefit of passing textual patient data to the image capture device or application to reliably associate patient (and perhaps encounter or procedure) data?

Even if orders are placed, most of the devices and applications used in Enterprise Imaging cannot accept an HL7 message and do not speak DICOM. Some form of broker would likely be required yet again.

Enterprise Information Interoperability for Enterprise Image Capture

One hope that we have is the adoption of the new HL7 FHIR standard. Based on REST-based API design methods, it is much easier to integrate with different devices (especially mobile devices) than HL7 v2.x messaging and DICOM interfaces are. Other methods used are to generate a URL from the EMR, with all the info provided in parameters, that launches the image capture application/device in context. Another method is to use HL7 messaging to populate the VNA database with patient, encounter and order/procedure information (essentially a copy of what the EMR has), and use a tool or API (perhaps the DICOMweb™ Query API, QIDO-RS) to query this system to get the necessary information.

Don’t Forget the Metadata and Supporting Information

This still leaves the issue of how to reliably and consistently capture the information that goes with the image(s)—notes, anatomy info, findings, technical exam info, observations, etc. In DICOM, when this type of information is needed, a SOP Class is defined. The header of the SOP Class object specifies where all this metadata should go. This is one of the primary principles of interoperability: a defined format and data scheme, with a clear and shared meaning.

Assuming that not all Enterprise Images will be generated in, or converted into, DICOM format, the definition of the metadata schema may be left to be defined by the implementing vendor.

In addition to the clinical and technical data, sooner or later, someone is going to be looking for operational data for use in analytics and process improvement, so it will need to be captured (on some level of detail), as well.

Consistent Terms

And, even when we have a common schema, if the terms used within the scheme are not consistent, we end up spending an enormous amount of time doing mappings or integrating terminology services (and even then, never fully addressing all cases).

To Acquire or Not to Acquire

If we think about Enterprise Imaging that is not “ordered”, what triggers the acquisition of an Enterprise Image? Is it up to the clinic or individual care provider to make the judgement? Should a published set of best practices define this? Would the EMR have logic, based on the patient’s condition or care pathway, to prompt or force the user to acquire and store the image(s)?

Enterprise Imaging Acquisition Protocols Needed?

If we consider the different ways that images can be captured (still, video), the subject in frame (cropping, zooming), lighting, etc., and the ability to capture a single image or a set of images, do we also need some form of a book of protocols to guide the person acquiring the images? Should certain images contain a ruler (or object of known size) to allow the image to be calibrated for measurements?

The Cost of Doing Nothing

If we consider the impact of not having methods to avoid data entry errors, or not having a common schema, not having common terms, and not even having a common communication protocol or best practices for acquisition workflows, what hope does Enterprise Imaging have?

Even with options for all these things, imaging and information devices are still struggling to be interoperable with departmental and enterprise applications, as described in this Healthcare IT News article, “Nurses blame interoperability woes for medical errors”.

The Future is Now(ish)

This is why the mission and output of the joint HIMSS-SIIM Enterprise Imaging workgroup (charter in PDF here) is so important. The space needs to be better defined, with acquisition workflow practices, data formats, schemas, terms, and protocols outlined.

If we simply try to copy what is done in Radiology into Enterprise Imaging, it will create too much of a burden on the people asked to capture these images, and they won’t do it, frankly. Unlike the reimbursement in Radiology, they often have little incentive to spend the extra time to capture, index and upload images to the EMR when they are focused on the patient.

But, if we ignore the benefits that come with the controls and methods we have developed and matured over the years in Radiology, we risk having to re-learn all the same lessons again. And that would be very sad (and expensive, and wasteful, and unsafe…).

Add on top of all this the increasing need to share this data across different enterprises for continuity of care and the importance of interoperable data portability/liquidity is critical.

The fundamental healthcare informatics knowledge and business analysis skills developed by imaging informatics professionals, through on-the-job experience and membership in educational/research societies like SIIM, will be important in determining the right mix of proven concepts that apply, and new methods and innovations. Without a supply of talent to foster the change, nothing will change.

In Conclusion…

When dealing with such an undefined space, people often relish the idea of “doing it right this time”. I would urge anyone involved in this space to reflect on what has been accomplished in mature fields like Radiology, as there are a lot of “right things” that we may be taking for granted. With a little modernization, we can still get continued value out of what we have already achieved.

Article – SIIM: Experiment in web technologies points to future of health IT

Here is an article summarizing the way Cleveland Clinic is using REST-based APIs to solve real problems in their institution. Taken from a talk given by Mat Coolidge at the SIIM 2014 Annual Meeting.

Article – SIIM Hackathon gives DICOMweb a coming-out party

Check out this article in Radiology Business Journal on the recently concluded Hackathon at the SIIM 2014 Annual Meeting in Long Beach, California.

Here are my other observations on SIIM 2014, in case you missed it.