The Case for Vendor Neutral Artificial Intelligence (VNAi) Solutions in Imaging

Defining VNAi

Lessons Learned from Vendor Neutral Archive (VNA) Solutions

For well over a decade, VNA solutions have been available to provide a shared multi-department, multi-facility repository and integration point for healthcare enterprises. Organizations employing these systems, often in conjunction with an enterprise-wide Electronic Medical Record (EMR) system, typically benefit from a reduction in complexity, compared to managing disparate archives for each site and department. These organizations can invest their IT dollars in ensuring that the system is fast and provides maximum uptime, using on-premises or cloud deployments. And it can act as a central, managed broker for interoperability with other enterprises.

The ability to standardize on the format, metadata structure, quality of data (completeness and consistency of data across records, driven by organizational policy), and interfaces for storage, discovery, and access of records is much more feasible with a single, centrally-managed system. Ensuring adherence to healthcare IT standards, such as HL7 and DICOM, for all imaging records across the enterprise is possible with a shared repository that has mature data analytics capabilities and Quality Control (QC) tools.

What is a Vendor Neutral Artificial Intelligence (VNAi) Solution?

The same benefits of centralization and standardization of interfaces and data structures that VNA solutions provide are applicable to Artificial Intelligence (AI) solutions. This is not to say that a VNAi solution must also be a VNA (though it could be), just that they are both intended to be open and shared resources that provide services to several connected systems.

Without a shared, centrally managed solution, healthcare enterprises run the risk of deploying a multitude of vendor-proprietary systems, each with a narrow set of functions. Each of these systems would require integration with data sources and consumer systems, user interfaces to configure and support it, and potentially varying platforms to operate on.

Do we want to repeat the historic challenges and costs associated with managing disparate image archives when implementing AI capabilities in an enterprise?

Characteristics of a Good VNAi Solution

The following capabilities are important for a VNAi solution.

Interfaces

Flexible, well-documented, and supported interfaces for both imaging and clinical data are required. Standards should be supported, where they exist. Where standards do not exist, good design principles, such as the use of REST APIs and support for IT security best practices, should be adhered to.

Note: Connections to, or inclusion of, other sub-processes—such as Optical Character Recognition (OCR) and Natural Language Processing (NLP)—may be necessary to extract and preprocess unstructured data before use by AI algorithms.

Data Format Support

The data both coming in and going out will vary and a VNAi will need to support all kinds of data formats (including multimedia ones) with the ability to process this data for use in its algorithms. The more the VNAi can perform data parsing and preprocessing, the less each algorithm will need to deal with this.

Note: It may be required to have a method to anonymize some inbound and/or outbound data, based on configurable rules.

Processor Plug-in Framework

To provide consistent and reliable services to algorithms, which could be written in different programming languages or run on different hosts, the VNAi needs a well-documented, tested, and supported framework for plugging in algorithms for use by connected systems. Methods to manage the state of a plug-in—from test, production, and disabled, as well as revision controls—will be valuable.

Quality Control (QC) Tools

Automated and manual correction of data inputs and outputs will be required to address inaccurate or incomplete data sets.

Logging

Capturing the logic and variables used in AI processes will be important to retrospectively assess their success and to identify data generated by processes that prove over time to be flawed.

Data Analytics

For both business stakeholders (people) and connected applications (software), the ability to use data to measure success and predict outcomes will be essential.

Data Persistence Rules

Much like other data processing applications that rely on data as input, the VNAi will need to have configurable rules that determine how long defined sets of data are persisted, and when they are purged.

Performance

The VNAi will need to be able to quickly process large data sets at peak loads, even with highly complex algorithms. Dynamically assigning IT resources (compute, network, storage, etc.) within minutes, not hours or days, may be necessary.

Deployment Flexibility

Some organizations will want their VNAi in the cloud, others will want it on-premises. Perhaps some organizations want a hybrid approach, where learning and testing is on-premises, but production processing is done in the cloud.

High Availability (HA) and Business Continuity (BC) and System Monitoring

Like any critical system, uptime is important. The ability for the VNAi to be deployed in an HA/BC configuration will be essential.

Multi-tenant Data Segmentation and Access Controls

A shared VNAi reduces the effort to build and maintain the system, but its use and access to the data it provides will require data access controls to ensure that data is accessed only by authorized parties and systems.

Cost Sharing

Though this is not a technical characteristic, the VNAi solution likely requires the ability to share the system build and operating costs among participating organizations. Methods to identify usage of specific functions and algorithms to allocate licensing revenues would be very helpful.

Effective Technical Support

A VNAi can be a complex ecosystem with variable uses and data inputs and outputs. If the system is actively learning, how it behaves on one day may be different than on another. Supporting such a system will require developer-level profile support staff in many cases.

Conclusion

Without some form of VNAi (such the one described here), we risk choosing between monolithic, single-vendor platforms, or a myriad of different applications, each with their own vendor agreements, hosting and interface requirements, and management tools.

Special thanks to @kinsonho for his wisdom in reviewing this post prior to publication.

Imaging Exam Acquisition and Quality Control (QC) Workflow in Today’s Consolidated Enterprise – Part 1 of 2

As existing healthcare provider organizations merge and affiliate to create Consolidated Enterprises, image acquisition workflows are often found to be different across the various facilities. Often, the different facilities that comprise the Consolidated Enterprise had different procedures and standard of practice for image acquisition and Quality Control (QC), along with different information and imaging systems.

Standardizing and harmonizing enterprise-wide policies, especially for imaging exam QC, can have significant benefits. A failure to standardize these workflows in a Consolidated Enterprise may result in inconsistent or inaccurate imaging records, which can lead to reading and viewing workflow challenges. These are compounded with a shared imaging system, such as an enterprise PACS or VNA, and can result in delays in care and patient safety risks.

There are generally two areas worth evaluating for optimization:

  • Technologist imaging exam acquisition workflow (Tech Workflow)
  • Imaging record Quality Control workflow (QC Workflow)

Here, we will explore Tech Workflow. QC Workflow will be covered in a subsequent post.

Throughout this discussion the term Radiology Information System (RIS) is used, which can be a standalone system or a module of an EMR.

Tech Workflow

The use of DICOM Modality Worklist (DMWL) for the management of image acquisition is well-understood and broadly adopted. However, the process of marking an exam as “complete” (or “closed”) following acquisition is less standardized and varies across different vendors and healthcare enterprises. The subsequent QC and diagnostic reading workflows rely on the “completion” of the exam before they can begin. For example, an exam that is never marked as “complete” may not appear on a Radiologist Reading Worklist, and an imaging exam that is marked as “complete” when it isn’t will be available for Radiologists to read with only a partial set of images.

Imaging Technologists typically interact with the following applications on a daily-basis.

Tech WF Screens

  • Modality Console – a comprehensive set of tools, attached to the modality, to perform image acquisition activities (such as DMWL queries, exam protocoling, post-processing, etc.).
  • Radiology Information System (RIS) – a specific view into the enterprise RIS application, allowing Technologists to look up patient/procedure information, a set of tools to document the acquisition and mark exam as “complete”, etc.
  • Image Manager/Archive (IM/A) QC – a comprehensive set of imaging exam Quality Control (QC) tools, provided by the Image Manager/Archive (IM/A), such as PACS or VNA, or a dedicated application, to make any necessary corrections to ensure the quality of acquired imaging exam records.

As stated above, there is significant variability among healthcare providers with respect to instituting Tech Workflow policies and procedures. The following diagram illustrates the steps involved in a common Tech Workflow.

Tech WF Flow

Notes:

  • In some cases, Technologists validate the quality of the image and confirm that the number of images in the IM/A is correct for multiple studies at a time instead of each one independently due to the high-volume of exams being acquired.
  • An ability to assess the quality of the imaging exam and correct it (if needed) in a quick and user-friendly manner is critical for an efficient exam completion workflow.

PACS-driven Reading Workflow

In this scenario, the PACS Client provides a Reading Worklist and it is typically responsible for launching (in-context, through a desktop integration) the Report Creator application. There are several methods used across provider organizations to communicate study complete status updates to the PACS.

Method Benefit Challenge
Time out – this is the most typical approach, which considers a study to be complete after a defined period of time has passed (for example, five minutes) since the receipt (by PACS) of the last DICOM object from the modality.
  • Easy to implement
If the time-out is too long, the creation of the corresponding Reading Worklist item will be delayed. Alternatively, a short time-out may result in a Radiologist reporting an incomplete study, which requires follow-up review and potentially an addendum to the report once the missing images are stored to PACS.
HL7 ORM – some organizations release HL7 ORM messages to the Report Creator only after the order status is updated (to study complete) in the RIS.
  • Easy to implement
  • Prevents reporting of incomplete exams (although relies on Technologists to validate the completeness of the study structure in the PACS)
There are scenarios where PACS has received DICOM studies, but their statuses in the RIS application has not yet been updated (for example, as can happen with mobile modalities). The Reading Worklist is unaware of the HL7 message flow between the RIS and the Report Creator and, therefore, allows the Radiologist to start reviewing cases. However, these cases have no corresponding procedure information in the Report Creator. When the Radiologists tries to launch the reporting application in the context of the current study, the Report Creator is unable to comply.
DICOM MPPS – Once an exam is complete, a DICOM MPPS N-Set message (issued by the modality) informs the PACS (and/or RIS) about the structure of the study and the fact that it is completed (along with other useful exam information).
  • Prevents reporting of incomplete exams
  • Automatic confirmation of the structure of the study

 

  • The adoption of DICOM Modality Performed Procedure Step (MPPS) is still limited in most enterprises, even though some modalities, RIS, and PACS support it.
  • Somewhat complex to implement (requires integration and testing between each modality and the MPPS server) coupled with a lack of understanding as to the benefits of this approach in many healthcare provider organizations.
  • Some modality vendors charge an additional fee for a license to enable MPPS integration.
  • Can be disconnected from the “completion” of the exam in RIS (i.e. can ensure the Report Creator’s readiness), provided only the PACS receives and processes the MPPS messages.
DICOM Storage Commitment – Once the exam is complete, a series of DICOM messages (N-Action, N-Event-Report) between modalities and PACS can determine whether a complete study was stored to PACS.
  • Prevents reporting of incomplete exams
  • Automatic confirmation of the structure of the study
  • Although most PACS and many modalities support this DICOM transaction, it is not widely implemented by healthcare providers.
  • Somewhat complex to implement (requires integration and testing between each modality and the PACS server) coupled with a lack of understanding as to the benefits of this approach in many healthcare provider organizations.
  • Can be disconnected from the “completion” of the exam in RIS (i.e. can ensure the Report Creator’s readiness).

RIS-driven Reading Workflow

In this scenario, the RIS provides the Reading Worklist and it is implicitly aware of the status of the exam (assuming the same system is used by Techs and Rads). It creates the worklist item that corresponds to the exam once it reaches the “complete” status. As the Reading Worklist launches both the Report Creator and the Diagnostic Viewer (PACS Client) applications, it does not face the informatics challenges inherent to the PACS-driven Reading Workflow described above.

Enterprise-wide Reading Workflow (Dedicated, Standalone Application)

Some organizations use an enterprise-wide Reading Worklist that is a separate application from the PACS and RIS to orchestrate enterprise-wide diagnostic reading (and other imaging related) tasks across all their Radiologists using fine-grained task-allocation rules. Similar to the RIS-driven Reading Workflow, the worklist launches both the Report Creator and the Diagnostic Viewer applications once a worklist item is selected.

To prevent the complexity of the PACS-driven Reading Workflow described above, some organizations choose to release an HL7 ORM message from the RIS application to the worklist only when the status of the corresponding exam in that system is updated. Alternatively, organizations that choose to send all ORM messages to the worklist application as soon as procedures are scheduled, need to deal with ensuring that the PACS has a complete study prior to allowing it to be reported.

So, what?

It is important for healthcare provider organizations to understand the relationship between the Tech Workflow and the Reading Worklist approach they adopt. If a RIS-driven approach is not chosen, then there should be a clear integration strategy in place to ensure that studies are not reported too soon or missed.

SIIM 2018 Annual Meeting: A Preview

SIIM18 graphic
Gaylord National Resort, National Harbor, MD

The SIIM 2018 Annual Meeting in Washington D.C. is just around the corner (May 31 to June 2). I look forward to seeing many friends, sharing ideas, and learning. I will be involved in number of sessions this year. Here is a preview.

Preparing for a Successful RFP and Contract with Vendors

Thursday, May 31 | 9:45 am – 10:45 am | Annapolis 1

In this roundtable session, participants will discuss how to best prepare for, develop, and issue an RFP, as well as how to analyze and grade the responses. We will also discuss how to best prepare for, and support, contract negotiations with a vendor.

Debate: Enterprise PACS vs. Vendor Neutral Archive (VNA): Choose Wisely

Friday, June 1 | 9:45 am – 10:45 am | Cherry Blossom Ballroom

Depending on your organization’s goals and scale of enterprise, the options available to you for an image archive can vary. In this debate-style session, we will explore the merits of using a Vendor Neutral Archive (VNA) vs. an archive provided as part of an Enterprise PACS. I am moderating the session.

Imaging IT Financials – Learn from the Masters

Saturday, June 2 | 12:45 pm – 2:45 pm | Baltimore 3/4/5

Participants that sign up for this learning lab (limited seats available) will work hands-on with experts to learn how to perform clear and compelling financial analysis. Two lab exercises—one focused on assessing cloud-based vs. on-premises image archive storage, and another on the IT investment required for rolling out the enterprise imaging solution to a newly acquired facility—will be worked on in teams. Each team will share their work with the other near the end of the session. Lab assistants will be on-hand to assist. Participants must bring a laptop or tablet with Microsoft Excel installed.

 

RSNA 2017: PACS Reconstruction

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.

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.

IHE Integration Profile Development – Vote Now (Voting Closed)

Update: Voting is now closed. Integration Profiles selected by the IHE committees for development in the 2016/2017 development cycle:

  1. Enterprise Scanner Protocol Management
  2. Critical Finding Follow-up and Communication
  3. Standardized Operational Log of Events

What healthcare use cases do you want addressed? What are the biggest interoperability issues facing our community today?

Provide your input to the IHE integration development process by completing the survey. Simply rank the six proposed profiles. It take 10 seconds.

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.

SIIM 2016: Where’s Don

SIIM2016

SIIM 2016 is almost here. If you are attending this year’s Annual Meeting, you may find these sessions that I am chairing of interest.

Developing an Imaging Record Quality Policy
Thursday, June 30 | 1:15 pm – 2:45 pm
Portland Ballroom 256

Strategies and Tactics for Capturing and Sharing Images
Friday, July 1 | 8:00 am – 9:30 am
Portland Ballroom 256

Strategies for Dealing with Patient Identities in a Consolidated Enterprise
Friday, July 1 | 1:15 pm – 2:45 pm
Portland Ballroom 256

Basically, just park yourself in Portland Ballroom 256 and I will come to you.

I will also be participating in the:

Hackathon Project Showcase (#SIIMHacks)
Friday, July 1 | 9:45 am – 10:45 am | Portland Ballroom 254

I look forward to catching up with some old friends and making some new ones over some craft beer!

VNA and Enterprise Viewer Projects’ ROI

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.