In what is becoming an annual tradition, I have written an article on Imaging IT trends for 2023, which is published in HealthCareBusiness.
Chronicling changes in both technology and industry with those in healthcare provider organizations, the article covers everything from Cloud, AI, Multimedia Reporting, to expanding expectations from healthcare provider system leadership from their staff.
Acknowledgements: I would like to sincerely thank Dr. Alex Towbin (@towbinaj), Ryan Fallon, and Jason Nagels (@jaynagels) for their time to review this information and provide valuable input.
Important Note: This article is in no way intended to dissuade organizations from sharing imaging exam data. As described within, there are many benefits to everyone, and sharing of imaging data should be consider a best practice. This article is intended to explore how vendors charge differently for storing imported imaging data in their systems.
The sharing of imaging exams across different enterprises has long been of value to patients and healthcare systems. From teleradiology, patient transfers, consults, treatment planning, to other scenarios, avoiding the repeat of an exam by sharing existing ones lowers costs, minimizes stress and frustration on the patient (and their family), and avoids any unnecessary radiation exposure.
As technology and reliable Internet has evolved, the norm of printing film, then exporting digital exams to portable media (CDs, DVDs, USB drives, etc.), has given way to cloud-based image sharing solutions. With these solutions acting as a secure broker among enterprises, imaging data can be easily moved from one organization to another. Patients can even upload their exam data using a webpage.
And while the managed movement of imaging data from one organization to another has become much easier and more common, the importation of the data to systems, like the PACS, at the destination enterprise often still requires some manual activity to get the exam data acquired at another enterprise to include all the unique data identifiers used at the destination enterprise.
The costs of the above activities are all well understood by imaging professionals, but there is another aspect that is less understood: Does the receiving imaging IT system vendor charge for imported exams?
In most jurisdictions (with private or public funded healthcare), a fee is paid by the payor for each imaging exam performed. This fee, commonly called the Technical Fee (or TechFee) in the U.S., is intended to compensate the health provider for the labor, equipment, consumables, facilities, IT systems, and other resources required to perform the exam and manage the resulting data. The TechFee amount will vary among different procedures and payors.
Note: A Professional Fee (ProFee) is also billed, but these funds may go to pay the Radiologist group, if they are not directly employed by the health system. So, even if an imported exam is read (for example, as an “over read”) and a ProFee bill generated, in some cases, the health system paying for the PACS does not receive any revenue (but do incur costs, as detailed below). Not to mention, ProFee billing for over reads can be unpopular among patients and referring physicians, as it increases overall cost of care.
It is common for PACS vendors to charge a software license for the use of the solution. The commercial model may vary between a licensed annual exam total allowed or a per use fee, but in most cases, the more exams that are acquired and stored by the organization, the more the vendor is paid. This is generally accepted as fair by both vendors and health system buyers.
Where there can be variability in vendor agreement terms is in deciding which exams are counted when determining compliance with the license terms or fees for usage. As the health system receives a TechFee for any exams they acquire, both vendor and health system provider are generally in agreement that these exams should count towards the software license.
But what about imported exams?
Some vendors treat all exams – acquired and imported – as equal and they are both included in the license compliance or usage calculations, even though the health system typically receives no compensation for imported exams. Some vendors may charge a lower fee for imported exams, while others include terms in the agreement that specify that only exams acquired by the health system, and not imported exams, are counted.
If multiple applications are involved – for example, a cloud-based image sharing solution, a local system for reconciling the imaging data with a local order, the PACS, and a Vendor Neutral Archive (VNA) – there may be the terms of solution’s software licenses to review and consider.
Before exploring how imaging IT vendors may count exams when determining system usage for software license calculations, let’s discuss some different ways in which imaging data are accessed and shared.
Image Viewer
Some enterprises provide a web-based image viewer, often as part of a referring physician or patient portal, to allow authorized users to see and navigate images and results. Cloud-based image sharing solutions also allow images temporarily stored to the solution to be viewed by authorized users. Similarly, Health Information Exchanges (HIEs) that support image data exchange usually also provide an image viewer to see the images. Common among all of these approaches is the ability to see and interact with the images without having to move the DICOM objects to the information-consuming enterprise, or having to reconcile the data to local identifiers or terms.
This is an efficient way to “browse” imaging data managed by an outside system and organization, but is often not efficient if advanced processing is required (if the image viewer lacks the features) or if the imaging data need to be closely compared to data stored in other systems (like the local PACS). While this method may suffice for some clinicians, Radiologists likely prefer the data to be presented in their primary system (linked to the local Patient ID and all other imaging records): the PACS.
Guest Studies
In some cases, the DICOM data is moved to the local PACS and stored temporarily. These data are available for viewing using all the PACS tools, but are not stored to the long-term archive. The system purges the data from the PACS cache based on any configured retention rules. These exams are often reconciled to local identifiers, like the local enterprise’s Patient ID, to make comparison in the system easy, but not all organizations will localize these data (see note below).
Many organizations will apply a specific labelling, such as a prefix or suffix character or string in the Study Description, to denote that the exam was acquired elsewhere. This can preempt any confusion if the acquisition protocol or image parameters are not consistent with the local policies. When used consistently, this method may also help identify the number of imported exams within an imaging IT system.
This approach is common where images are shared with an organization, through an image sharing solution or portable media, and the local PACS is the preferred viewer (due to its advanced tools and/or system familiarity). It is also used where Radiologists need to review the imaging data for scenarios like teleradiology or consults, but the patient is not being transferred or admitted to the local organization.
Archived Exams
Like Guest Studies above, these exams are received, stored, and (typically) reconciled to include local identifiers (for example, Patient ID and Accession Number) and terms (for example, an updated Study Description). They are archived to the PACS or VNA and made part of the local enterprise’s patient medical record.
This is common where the patient is going to be transferred to the local enterprise or will be getting diagnostic or clinical services, such as a follow-up imaging exam or surgery, and the enterprise wishes to retain these records for future reference.
Notes:
Many vendors run a query against the imaging IT system to collect a count of all imaging exams stored to the system over a period (for example, a year). They count each exam that has a unique Study Instance UID value (a required DICOM attribute). This method would include all stored exams, including imported exams.
Another method is to have the health system produce a report from their RIS that provides a count of all imaging exams performed by that enterprise. This list could exclude imported exams and would generally represent exams for which the health system received revenue in the form of TechFees. The vendor would have to trust the health provider’s report, but a sanity check against the imaging IT system’s database would suggest if the information were within reason.
So, is this aspect worth looking into? Let’s look at some numbers.
Imagine a large healthcare enterprise that stores a total of 1 million imaging exams to their PACS each year. As an academic system with lots of affiliations, this enterprise has many patients in the area routinely referred for additional imaging and treatment.
Their vendor charges $1.50 per exam stored to the system.
If we assess different percentages of the total exam volume that is imported, we see that the cost to store imported exams could vary from $150K to $375K.
Keep in mind that the health system has no TechFee revenues to offset these costs (though there may be other clinical or diagnostic services that the patient receives for which the health system can bill).
In the above case, if the vendor licenses the software based on a total number of annual exams, as long as the total annual exams stored does not exceed the amount currently licensed, no additional software license needs to be purchased. If the vendor counts imported exams in the total, and image sharing increases, it may require the health system to purchase additional licenses (for example, to allow another 50K to 100K annual exams to be stored), even though they receive no revenue for the imported exams.
If the vendor licenses the imaging IT solution on a per-exam usage fee, and they count imported exams, the health system would have to pay the vendor for each exam imported (at whatever rate they specify in the agreement, which may be the same as an acquired exam, or at a lower rate).
Today, most healthcare providers procure and manage their own hardware (for example, servers, storage, and network equipment) and the solution vendor supplies the software, technical and professional services, along with ongoing support. So, in addition to any software license costs paid to the imaging IT vendor, the health system also must supply the hardware to store and manage the imported exams, and the labor to perform the importation. If a data migration is performed sometime in the future, the health system will have to pay for any imported exams that are included in the migration.
This is all in addition to any fees paid for an image-sharing solution.
The above details are important to consider if a cloud-based PACS solution is considered.
When a system is on-premises (for example, hosted in the health system’s data center), the vendor may be willing to acknowledge that the imported exams do not count towards the total exam volume when calculating the software license, but when they also provide all the hardware infrastructure, they will incur costs for all data stored. This may result in some fee being charged to the health system.
While beyond the focus of this article, many of the same questions should be posed when storing clinical images, also called Enterprise Imaging (EI) content, to the imaging IT system. Most of these data sets are not captured in response to an ordered service and have no billing associated with their capture or storage. If the imaging IT solution vendor counts these data sets (which may be one or more image, video, audio file, document, etc.) as an exam when determining software license compliance or system usage, costs (with no associated revenues) could be higher than expected.
Another significant cost of image-sharing is the labor involved in reviewing, importing, and reconciling the imaging data to use local identifiers. This cost is not hidden, but is not measured by most enterprises, and these costs can be larger than many people understand. Industry vendors have worked on solutions to auto-generate the necessary order information to perform reconciliation automatically. New data standards, like HL7 FHIR® (https://www.hl7.org/fhir/), and APIs that support them developed and deployed in EHRs make this approach more feasible. Careful attention needs to be paid to how data elements like Study Description are applied in the reconciled data, as how procedures are labelled vary among enterprises. Inconsistent Study Description values can affect relevancy rules for pre-fetching and routing and may necessitate maintaining complex terminology mapping tables (if supported by the imaging IT solution). Series descriptions, which often affect features like display protocols, also vary among modalities and enterprises. Terminology normalization is a complex challenge involving many unmanaged data variables that some believe may be solved more effectively through the application of Artificial Intelligence (AI).
The first step is understanding your current situation with the following factors to consider:
If your organization is looking to replace an imaging IT system, like a PACS or Vendor Neutral Archive (VNA):
The purpose of this article is not to dissuade enterprises from sharing imaging exam data. As stated, there are many benefits of this activity to all stakeholders, most notably the patient. The purpose here is to explore variability in how imaging IT solution vendors count exams for software licensing, and how this can add up to represent significant costs, over time.
It would be unwise to select a new imaging IT solution simply based on whether they count imported exams toward the software license or not, but it should be considered in your cost projection calculations.
And it may be worthwhile to educate your imaging IT vendor partner on the economics of providing diagnostic imaging services and to align their compensation to reflect the scale of the enterprise’s revenues.
In my previous post, I discussed common challenges associated with the imaging exam acquisition workflows performed by Technologists (Tech Workflow) that many healthcare provider organizations face today.
In this post, we will explore imaging record Quality Control (QC) workflow.
A typical Consolidated Enterprise is a healthcare provider organization consisting of multiple hospitals/facilities that often share a single instance of EMR/RIS and Image Manager/Archive (IM/A) systems, such as PACS or VNA. The consolidation journey is complex and requires careful planning that relies on a comprehensive approach towards a solution and interoperability architectures.
An Imaging Informatics team supporting a Consolidated Enterprise typically consists of PACS Admin and Imaging Analyst roles supporting one or more member-facilities.
To ensure the quality (completeness, consistency, correctness) of imaging records, providers rely on automatic workflows (such as validation by the IM/A system of the received DICOM study information against the corresponding HL7 patient and order information) and manual workflows performed either by Technologists during the Tech Workflow or by Imaging Informatics team members post-exam acquisition. Automatic updates of Patient and Procedure information are achieved through HL7 integration between EMR/RIS and the IM/A.
Typical manual QC activities include the following:
One of the key challenges related to ensuring the quality of imaging records across large health system enterprises is determining who is qualified and authorized to perform QC activities. A common approach is to provide data control and correction tools to staff from the site where the imaging exam was acquired, since they are either aware of the context of an error or can easily get it from the interaction with the local clinical staff, systems, or the patient themselves. With such an approach, local staff can access only data acquired at sites to which they are assigned to comply with patient privacy policies and prevent any accidental updates to another site’s records. The following diagram illustrates this approach.
Another important area of consideration is to determine which enterprise system should be the “source of truth” for Imaging QC workflows when there are multiple Image Manager/Archives. Consider the following common Imaging IT architecture, where multiple facilities share both PACS and VNA applications. In this scenario, the PACS maintains a local DICOM image cache while the VNA provides the long-term image archive. Both systems provide QC tools that allow authorized users to update the structure or content of imaging records.
Since DICOM studies stored in the PACS cache also exist in the VNA, any changes resulting from QC activity performed in one of these systems must be communicated to the other to ensure that both systems are in sync. This gets more complicated when many systems storing DICOM data are involved.
Integrating the Healthcare Enterprise (IHE) developed the “Imaging Object Change Management (IOCM)” integration profile, which provides technical details regarding how to best propagate imaging record changes among multiple systems.
To minimize the complexity associated with the synchronization of imaging record changes, it is usually a good idea to appoint one system to be the “source of truth”. Although bidirectional (from PACS to VNA or from VNA to PACS) updates are technically possible, the complexity of managing and troubleshooting such integration while ensuring good data quality practices can be significant.
Often the QC Workflow is not discussed in depth during the procurement phase of a new PACS or VNA. The result: The ability of the Vendor of Choice’s (VOC) solution to provide robust, reliable, and user-friendly QC tools, while ensuring compliance with access control rules across multiple sites, is not fully assessed. Practice shows that vendors vary significantly in these functional areas and their capabilities should be closely evaluated as part of any procurement process.
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.
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.
The following capabilities are important for a VNAi solution.
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.
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.
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.
Automated and manual correction of data inputs and outputs will be required to address inaccurate or incomplete data sets.
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.
For both business stakeholders (people) and connected applications (software), the ability to use data to measure success and predict outcomes will be essential.
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.
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.
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.
Like any critical system, uptime is important. The ability for the VNAi to be deployed in an HA/BC configuration will be essential.
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.
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.
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.
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.
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.
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.
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.
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.
In just less than a month from today on Friday May 4, 2018 (Star Wars day!), the annual MIIT (Medical Imaging Informatics and Teleradiology) conference will once again be held at the beautiful Liuna Station in Hamilton, Ontario, Canada.
This year’s theme is Connecting Imaging and Information in the Era of AI and the program features several distinguished speakers from Canada and the U.S.
Talks will cover EMR implementation, Radiology Outreach, the link between Quality and Informatics, Highly Automated Radiology (using AI), an update on IHE, and a comparison of PACS+VNA vs. Regional PACS. It will also have a panel on the impact of EMRs and AI on Radiology and a talk on AI by a speaker from IBM Watson Health.
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.
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.
Update: Voting is now closed. Integration Profiles selected by the IHE committees for development in the 2016/2017 development cycle:
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.
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:
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:
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:
| 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.
Don K Dennison 