Interoperability

Managing Patients’ Preferred Name in Imaging IT Systems Using Standards

dondennison Healthcare IT , , , ,

Acknowledgements: I would like to acknowledge and thank Kinson Ho and Brad Genereaux for their time, knowledge, and wisdom in contributing to this article. I would also like to thank Jason Wong for his inspiration to write this article and valuable review feedback.

Patient name values within healthcare IT systems have often been treated as simple data elements. While they can be structured to capture first and last name, along with other elements like middle name or initial, they represent a singular concept. However, in the real world, people often wish to be referred to by a different name (or names) than their legal name.

The motivation for capturing a preferred name can be as simple as a preference (Don vs. Donald), a celebrity moniker (Sting vs. Gordon Sumner), a VIP patient pseudonym, gender-affirming, providing a simplified version of a hard-to-pronounce name, or other reasons.

Note: In the context of this article, the term preferred name refers to a name that differs from legal name (and potentially others). If a patient legally changes their name so that their preferred name is now their legal name, this topic is likely moot (the patient has a single name representation in this case).

Background

In healthcare IT systems, including imaging IT and those systems supporting them, managing patient identity so that digital information is associated with the correct patient is a well-established priority with methods defined in standards like HL7 (v2, v3, and FHIR) and DICOM. Effectively managing a patient’s identity is critical for administrative operations within the hospital, including ingesting externally created records, as well as for billing activities.

The functional capability of imaging IT systems, like PACS, to manage patient identity varies, especially in multi-patient identity domain environments. A model for assessing the capabilities of imaging IT systems to manage patient identity is proposed in the JDI article “Patient Identity Management Maturity Model (PIM3) for Imaging Information Technology Systems” (Ref: https://link.springer.com/article/10.1007/s10278-021-00429-2).

But patient identity management is primarily about indexing health information with a person. How a person identifies and prefers to be identified by healthcare provider staff when receiving care is a very different topic.

For a primer on the various aspects of this – including a glossary of relevant terms, such as Gender Identity, Recorded Sex or Gender, Sex for Clinical Use (SFCU), and Name to Use (NtU) – refer to the JAMIA article “Gender harmony: improved standards to support affirmative care of gender-marginalized people through inclusive gender and sex representation” (Ref: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8757317/).

Let’s also highlight the efforts of the healthcare standards organizations to incorporate an expanded list of values for gender identity. (Ref: https://build.fhir.org/ig/HL7/fhir-gender-harmony/ and https://www.dicomstandard.org/news-dir/current/docs/sups/sup233.pdf)

Managing Preferred Names within Healthcare and Imaging IT Systems

Before exploring how to capture, exchange and manage preferred name values across systems, let’s summarize the common practices and methods in use today. Below, the typical communication of information containing patient information among systems (or functional modules of larger systems), such as the Electronic Medical Record (EMR), Patient Administration System (PAS) and Radiology Information System (RIS), are illustrated.

Legend: PACS = Picture Archiving & Communication System; DMWL = DICOM Modality Worklist; DICOM = Digital Imaging and Communications in Medicine; HL7 = Health Level 7; ADT = Admit-Discharge-Transfer (an HL7 message type intended to communicate patient information); ORM = an order for services (in this context, for a diagnostic imaging exam, like an x-ray or ultrasound)

Notes:

  1. The PAS and RIS are shown as modules of an EMR above, as this is increasingly common within healthcare IT environments within jurisdictions like the U.S., but these could alternatively be separate systems.
  2. The DMWL server is shown above as being provided by the RIS, but this could alternatively be the PACS or another system that is receiving orders for exams to be acquired.
  3. Another important system (not shown above) to consider is the reporting solution, which will receive HL7 ORM messages, and potentially HL7 ADT messages. Whichever approach for managing patient preferred name values is adopted, it is important that the value presenting in the PACS, reporting solution, and any other application user interfaces visible during exam review, present the same patient name value to avoid any confusion and concern among Radiologists.

Patient information is communicated across systems in a variety of transactions and protocols and formats. The most common method for communicating patient-related information today is via HL7 v2.x ADT messages. In cases where HL7 ADT is not possible, the patient information provided in HL7 ORM (order for an imaging exam) may be used. Though newer methods, like those provided through Web-based APIs defined in HL7 FHIR (Ref: https://www.hl7.org/fhir/), are emerging – due in part to the U.S.’s 21th Century Care Act that mandates EMR system unblock data access – sending HL7 v2.x ADT messages to systems external to the PAS remains the dominant approach today.

Patient information, including the patient’s name, is also provided to imaging modalities through the DMWL. Patient information is additionally provided in the orders provided to the PACS.

Where a DMWL server is not available to the imaging modality (for example, during a system downtime), patient information may be entered at the modality console by the performing technologist/radiographer (“Tech”).

Best Source of Data

Typically, the patient information provided in HL7 messages should be treated as the authoritative value and stored within the databases of any ancillary systems, like PACS. ADT messages can communicate complex, multi-value and multi-domain patient identity, include extended information on the patient, automate patient record updates and merges, and perform other patient-level information management functions.

As orders may come from a RIS that is separate from the PAS, it may (and often does) include less patient information than what is included in an ADT message. As the DMWL server data is provided from placed orders, it may also present limited patient information.

The patient information provided within the DICOM objects from the myriad of imaging modalities across a healthcare enterprise can vary in completeness and correctness (especially if entered by the Tech).

Given the above, it is considered best practice for ancillary systems to use patient level information from ADT messages, and only when this is not available to rely on ORM messages. If neither are available, the information provided in the attributes of the DICOM objects must be relied upon. When evaluating imaging IT systems, like PACS, understanding how information is applied to the database, based on the source (for example, the PAS or the modality) is important – simply using the values contained in the last message received is considered problematic.

The above is important to understand when trying to communicate preferred patient name values across these systems using existing transactions.

Presenting Patient Names

Patient names appear in many locations throughout the care cycle, including in the computer applications used by healthcare providers, such as the EMR and PACS, as well as referring physician and patient-facing portals. They also appear on non-digital materials, like printed requisitions and results, patient wristbands, and medical reference materials provided to patients.

Ensuring the preferred name is consistently visible in all these locations is the focus of this article. Note that this article focuses mostly on the interoperability of and availability of presentation of this information within application, but does not deal with user experience design (UXD) issues to ensure all the intended name information is presented within the space available and easily understood by users.

SystemRISDMWL & ModalityPACS
ImpactDuring exam scheduling & patient communicationDuring imaging exam acquisitionDuring interpretation
During review of images by clinicians & patients

Without a comprehensive and reliable solution, the name presented for a patient may be different in different systems and on materials, potentially leading to confusion, frustration, delays in care, and even medical errors.

Also, if a patient has a preferred name and it is not used when communicating with them, it may have a negative impact on patient satisfaction survey scores (Ref: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4716244/ and https://www.the-hospitalist.org/hospitalist/article/121881/name-recognition-personalization-key-patient-experience and https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5653959/)

Capturing Patient Aliases

The first step for managing preferred patient names is having a PAS that allows aliases to the patient’s registered legal name (used for insurance, billing, and other purposes) to be entered and associated with their patient identity.

Assuming that this is functionally possible, a policy and procedure as to when and how to capture any patient aliases should be defined and communicated. Staff training should also be provided.

For each alias, it is considered useful to capture its purpose (if possible).

Communicating Patient Aliases

Following the transactions defined in the prior section, there are options for providing the patient’s preferred name value within the defined transactions. As part of exploring these options, an assessment of the data integration and functional capabilities of each of the involved systems is required. Depending on the capabilities of the systems involved, different approaches may be necessary.

Tactical Approaches for a Solution within Imaging IT Systems

Assuming the PAS has the capabilities to capture and provide a patient’s preferred name through a data interface (such as an HL7 ADT message), it is important to evaluate the downstream systems, such as the RIS, DMWL server, imaging modalities, and PACS to understand whether they can accept and properly manage and present the preferred name value(s).

Note: Where the PAS can capture and provide the purpose of a preferred name, the systems receiving this data, like the PACS, should be evaluated to assess whether the purpose can be stored and presented appropriately in the user interface.

Following a review of the involved systems in the subsections below, a table specifying the various transactions and references to standards that may provide a solution for communicating preferred name values is provided.

RIS

As the RIS is used by many healthcare provider roles – like exam schedulers, Radiology receptionists, porters, and the Technologist – that interact with the patient, having the preferred name value available for use is important.

If the RIS, like the PAS, is a module of the EMR, it is highly likely that both the legal and preferred name values are available for use. If the RIS is a separate system, a method to communicate the preferred name via HL7 is likely required.

DMWL

As the DMWL provides the imaging modality with patient and procedure information to include in the attributes of the captured images, having the patient name value match seen on the modality console match the value visible in the RIS, on the patient’s wristband (if present), and any paperwork provided will help avoid any confusion when the Tech is confirming the patient is the right person to be imaged for the procedure they are about to perform.

To maximize compatibility with a wide variety of imaging modality devices, the DMWL interface typically (and intentionally) provides a simpler set of fields to the modality than is provided in HL7 messages (ADT, ORM) to imaging IT systems, like PACS.

Imaging Modalities

Even if a DMWL server were able to present both the legal and preferred name values (it cannot based on the returned attributes defined by the standard; Ref: https://dicom.nema.org/medical/dicom/2014c/output/chtml/part04/sect_K.6.html), it is unrealistic to assume that all imaging modalities used in an enterprise would have the capability to store that information reliably and consistently in an appropriate DICOM attribute.

PACS

When DICOM images are sent from the imaging modality to PACS, the PACS should augment and update the patient and procedure information associated with the exam images using the field values provided in the HL7 ADT and ORM messages.

As an image management system, typically with interfaces from the PAS and RIS, the PACS may be able to store both the legal and preferred names, if the information model in the database schema was designed to accommodate multiple values.

This is likely not the case, however, as the design of many PACS available on the market today were established many years ago. Some were first released decades ago. The core information model for many has remained largely unchanged. This is because changing core information models can have a large impact on the overall design, function, and operation of the system. Because of this, these types of changes are often considered risky, requiring extensive testing to ensure no functional regression is introduced. This kind of change can also require a more complex than usual system upgrade to be performed.

As healthcare provider enterprises seek to adopt methods to manage preferred names, imaging IT system vendors may adapt their applications to support them. Healthcare providers may wish to advocate for enhancements to support the receipt and management of multiple patient names, along with all other patient identity value management, along with each values purpose.

Methods to Communicate Preferred Name Using Existing Data Standards

There are two basic approaches for dealing with preferred names using existing data communication standards (HL7, DICOM):

  1. Attempt to pass both legal and preferred name values in each transaction and rely on the ancillary systems to manage which to present and with the correct labelling (to distinguish between the values for users and systems).
  2. Maintain the legal and preferred name values in the PAS (and EMR) and include only the preferred name value in the standard Patient Name field/attribute.

Which Approach to Choose?

Let’s analyze the options above (1 & 2) using existing data standards.

Option 1 – Communicate Both Legal and Preferred Names Across Systems

There are optional fields and attributes that can be used to pass alternate patient name values, such as the preferred name. A summary with notes is below.

StandardField/AttributeNotes
HL7 v2PID.5 Patient NameAs of v2.3.1, the standard supports multiple Patient Name values, separated by “~”. Several codes for different name types are defined (see table below).
HL7 FHIRHumanNameFHIR supports multiple names and includes “use” as a coded value to define the purpose of each name (Ref: https://www.hl7.org/fhir/datatypes.html#HumanName).
DMWLPatient’s Name (0010, 0010)   and   Other Patient Names (0010, 1001)      Assuming the modality does not query the DMWL using any part of the Patient Name (for instance, the last name), the worklist item returned to the modality will include the Patient Name field, and the value it contains will be determined by the DMWL.   If the modality does query the DMWL using part of the Patient Name, whichever representation the Tech enters will need to match the value provided in the Patient Name attribute by the DMWL. That is, if the Tech enters the preferred name, and the DMWL has the legal name in the Patient Name attribute, it may not return a match.
DICOM ObjectsPatient’s Name (0010, 0010)   and   Other Patient Names (0010, 1001)This attribute is Type 3, meaning it is Optional.   Also, the DICOM standard does not define a code, qualifier, or descriptor to label the purpose for any of the Other Patient Name values included; therefore, it is up to the downstream system to determine how to manage and label these values in any database and UI.

Notes:

  • In most enterprises, there may be more than one PACS and more than one system that receives and presents DICOM data. For example, post-processing solutions. For Option 1 to be acceptable in all contexts, every system that could store and present the DICOM data would have to support the proper management of multiple representations of the patient’s name.
  • A sampling of DICOM Conformance Statements for popular PACS solutions indicate reasonable support for the receipt of DICOM objects that include the Other Patient Names (0010, 1001) attribute. In addition to the limitation noted above, it is important to understand that just because a DICOM-enabled system, like PACS, can accept an attribute, it does not ensure that the desired value is properly updated according to HL7 ADT and presented in the UI in the intended way. Prior to adopting Option 1, a complete walkthrough of the UI of all systems should be conducted to validate that the preferred name is presented as desired.
  • It is important to note that, even when a system like a PACS supports the Other Patient Names (0010, 1001) attribute, the DICOM standard does not define any structure to identify the intent or function of the value, which can lead to interpretation of its meaning. Even if an enterprise is very disciplined with their use of this DICOM Attribute to contain only a defined meaning (like preferred name), this may be difficult to maintain with image sharing across enterprises (other enterprises may use this attribute for another purpose).
  • Many PACS and other imaging IT systems allow appropriately privileged roles to view the entire DICOM header. Consideration should be made as to the risk or benefit from having users in this role see the multiple representations of the patient’s name, when stored within DICOM attributes.

HL7 defines coded values with definitions to be used to label the intended purpose (type) of each name. An extract of the table is provided below for reference (see the link below the table for extended information on each item listed, along with deprecated codes not included here).

CodeDisplay
AAssigned
BBirth name
BADBad Name
CAdopted Name
DCustomary Name
FFathers Name
ILicensing Name
KBusiness name
LOfficial Registry Name
MMaiden Name
MSKMasked
NNickname
NAVTemporarily Unavailable
NBNewborn Name
NOUSENo Longer To Be Used
PName of Partner/Spouse
RRegistered Name
RELReligious
SPseudonym
TIndigenous/Tribal

Reference: https://terminology.hl7.org/CodeSystem-v2-0200.html

Option 2 – Communicate Only Preferred Name to Ancillary Systems (like PACS)

In this approach, the multiple patient name representations are managed in the PAS (and EMR). All downstream transactions – including HL7 ADT and ORM, and DMWL – would include the preferred name value in the default Patient Name field/attribute.

This approach is the least technically challenging for downstream ancillary systems – likely no changes are required. It provides the preferred name for healthcare provider staff interacting with the patient and their guardians/advocates.

If patient wristbands and printed documents also use the preferred name, the information will all match and will reduce confusion, frustration, and risk of errors.

As the upstream EMR/RIS solution would typically manage billing charge submission, this system would be responsible for including the patient’s legal name in filings.

Additional Notes

  • In this scenario, it will be important for the PAS/EMR to clear present both the legal and preferred name(s) and for healthcare provider staff to be aware of where this is presented in the system UI and the meaning of each value, to avoid any confusion or concern when viewing both the PACS, Reporting, and EMR screens at the same time (as the preferred name would be the only value presented in the ancillary Radiology systems).
  • If a preferred name is entered after an initial patient registration, an HL7 ADT message to update the downstream ancillary systems can be sent (this approach would work for option 1 or 2 above).

Summary

Though data standards exist for communicating multiple representations of a patient’s name (Option 1), the number of downstream systems and devices that would have to support receipt of multiple patient name values, store and manage them, and present them appropriately in any UI and data interface (based on purpose and function) is too many to realistically expect broad success in large and complex enterprises.

Using the preferred name as the lone and default Patient Name value (Option 2), limits the downstream ancillary systems to presenting this value, but it will be helpful for patient interactions and for managing procedures. By maintaining the complexity of multiple patient names (legal, preferred, and potentially others) in the upstream EMR/RIS, and adapting that system to present the correct name representation in the different interfaces (for example, legal in billing, preferred in clinical portals), enterprises can limit the risk and complexity of managing multiple representations in downstream ancillary systems.

Given the importance of identity to patients, the definition of multiple patient identity values within the data communication standards (HL7, DICOM) and the support for capturing, storing, presenting, and communicating multiple patient identities and names in today’s EMR systems, healthcare providers should follow-up with their imaging IT vendors to advocate for enhancements within the systems available.

A Practical Conversation about Enterprise Imaging Webinar 

dondennison Healthcare IT , , , , , ,

On Friday, November 18, 2022, 12:00pm – 1:00pm ET, I will be participating in a webinar with the esteemed Dr. Chris Roth, MD, MMCI, FSIIM.

Covering a wide range of topics related to enterprise imaging, PACS, and trends in imaging informatics, Jason Nagels and David Kwan will moderate.

There is no cost to attend, but you must register. More information here.

Enterprise Imaging Webinar

Friday November 18, 12-1 pm ET

Article: Assessing the Next Generation of Imaging IT

dondennison Healthcare IT , , , , , , ,

HealthCareBusiness asked me to provide an article on some of the trends that I have been seeing in Imaging IT, including RIS, Reporting, and PACS (including Enterprise Imaging, Cloud, AI, and Pricing Models), along with some other general market trends.

If you prefer to read it in the magazine’s reader app (runs in your browser), you can use this link.

Trends in Imaging IT

The Hidden Cost of Importing Imaging Exams

dondennison Financials , , , , ,

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?

Imaging Exam Acquisition Revenues and PACS Costs

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.

Do you Need to See the Images or Have the Images?

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:

  • Documented organizational policies and procedures that define when and how outside imaging exams are accessed and imported should provide guidance to staff and affiliates.
  • Determining whether an outside exam is beneficial or necessary to import requires significant knowledge. Often, a Radiologist is required to make this decision, but in some cases an experienced imaging analyst with deep Radiology knowledge, like a senior Technologist, may be able to make this determination in many cases.
  • For Guest Studies and Archived Exams, if the data are not reconciled to local identifiers, there are some risks that the outside identifiers match local ones, which can result in a potential patient risk (exam linked to wrong patient). It can also cause issues when searching for data (some demographic values as stored in the DICOM data need to be known), resulting in some clean-up activities during a data migration.

Exam Counting Methods

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.

How Much Difference Does this Make?

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.

Example: Impact of Imported Exams on Imaging IT software license costs

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).

The Model Matters

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).

Other Costs and the Cloud

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.

Sidenote: Enterprise Imaging

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.

Sidenote: Labor for Importing and Reconciling Exam Data

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).

Tips for Minimizing Costs

The first step is understanding your current situation with the following factors to consider:

  • Do an inventory of acquired (check the RIS) and imported exams for each year for the past three years. Understand how many exams you are importing (with no offsetting revenue) and look for any trends. Are exam imports increasing year-over-year?
  • Read the agreement with your current vendor to understand the terms around how exams totals are counted. Understand whether they differentiate between acquired and imported exams. Understand whether Guest Studies (as described in this article) are counted, even though they are not archived.
  • If your imaging IT vendor does count imported exams when calculating the software license or usage, make sure you account for these costs when budgeting capital and operating budgets.
  • Understand the fees for any image-sharing solution you use. Does the vendor charge a different amount for exams that are viewed from the cloud, but not imported to the local PACS? Do they charge both the sender of the data and the receiver, or just one of the parties?
  • Review your policies and procedures for exam importation. Are they clear so that the necessary exams get imported, but ones that are not relevant are not?

If your organization is looking to replace an imaging IT system, like a PACS or Vendor Neutral Archive (VNA):

  • Ask the bidding vendors how they determine which exams are included in the count for software license calculations. If some do count imported exams and some do not, include an estimate of the additional costs for those that do in your Total Cost of Ownership (TCO) analysis.

In Conclusion

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.

Join us Online (and get your CE credits) for the First Virtual MIIT Meeting on Fri May 15!

dondennison Healthcare IT , , , , , , , , , ,

Now Online!

Why MIIT Went Virtual

As someone that has mostly worked from home for over seven years, I understand the value of digital communication and collaboration. In healthcare, we have had many digital tools for more virtual experiences, but have been slow to adopt them. The COVID-19 pandemic has caught many organizations with paper-based and analog processes flat footed.

Education is no different than healthcare and other organizations that have heavily depended on in-person settings. While there is no doubt an in-person conference is more personal and provides social networking opportunities, content can easily be delivered online (the slides and audio are all digital, right?).

This year’s Medical Imaging Informatics and Teleradiology (MIIT) meeting was scheduled to take place in-person in Hamilton, Ontario, just like it has for well over a dozen years. Given the current situation we are all facing, my Co-Chair Dr. David Koff (@koff14) and I were faced with a choice: cancel or try to continue with an online version. As we believe strongly in the importance of imaging informatics education, and the value in this year’s excellent program, we chose the latter.

The first virtual MIIT will take place on Friday May 15, 2020. We have lowered attendee and sponsor rates in consideration of the lower costs of operating a virtual meeting.

Program

We have a great program this year with Dr. Tessa Cook from UPenn, Dr. Vamsi Narra from BJC, Dr. Cree Gaskin from UVa, Les Folio from the NIH, Dr. Adam Prater from Emory, Michael Toland from UMMS, Ted Scott from HHSC, along with Kevin O’Donnell providing an update on the DICOM standard at MIIT 2020 and MIIT’s own Britt Tomlin providing an update on Alberta’s province-wide Connect Care CIS program.

Review the full program here.

Costs

At only CAD$80 per person (which, at the current exchange rate, is only US$57 for our American friends), and with accreditation for CE credits, it is very high value. There are no travel costs and imaging informatics professionals can join from anywhere in the world.

Register using the “Register Now” button at miit.ca.

Sponsorship

Sponsorship of MIIT is still available, starting as CAD$1,000 (~US$715 with today’s exchange rate). Higher tier sponsors are given high visibility with attendees and the opportunity to give a brief talk during the lunch hour.

Be sure to stay top-of-mind among imaging IT decision makers and influencers (from anywhere now) to make up for lost contact at cancelled meetings, conferences, and trade shows!

More information is available here.

More Information

If you have any questions, email us at info@miit.ca.

MIIT 2019 – An Overview

dondennison Healthcare IT , , , , , , , , , ,

On Friday, May 10, I once again have the pleasure of co-chairing the Medical Imaging Informatics and Teleradiology (MIIT) conference at Liuna Station in Hamilton, ON.

The program for the 14th annual MIIT meeting is stellar, we have a record number of sponsors, and—thanks to lower registration fees and new group discounts—many people are already signed up to attend.

Program Highlights:

  • AI Strategy of CAR – Roger Tam will enlighten us on the Canadian Association of Radiologists’ strategy for AI.
  • Cloud Services for Machine Learning and Analytics – Patrick Kling will reveal how cloud-based solutions can address the challenge of managing large volumes of data.
  • Patient-Centered Radiology – Dr. Tessa Cook (@asset25)will provide insight into their progress on this topic at UPenn.
  • Collecting Data to Facilitate Change – Dr. Alex Towbin of Cincinnati Children’s Hospital (@CincyKidsRad) will show us how to use data to support change management.
  • Panel on the Future of DIRs in Canada – In this interactive session, we will discover what has been accomplished with Diagnostic Imaging Repositories (DIRs) in Ontario, and what’s next. I will moderate a panel with leaders from SWODIN and HDIRS.
  • Practical Guide to making AI a Reality – Brad Genereaux (@IntegratorBrad), with broad experience working in hospitals, industry, standards committees, and technology, will help attendees prepare for this new area.
  • Healthcare IT Standards – Kevin O’Donnell, a veteran of healthcare standards development and MIIT, will provide an overview of developments within the DICOM and HL7 standards, and IHE.
  • ClinicalConnect – Dale Anderson will provide an update on this application (@ClinicalConnect), used by many organizations in the local region.

If you can attend, I am sure you will find the event educational. There are lots of opportunities to interact with our speakers and sponsors. If you are not from the region, you may find a weekend getaway to the nearby Niagara on the Lake wine region enjoyable.

And don’t forget to follow MIIT (@MIIT_Canada) on Twitter!

Enterprise Insight in Today’s Consolidated Enterprise

dondennison Healthcare IT , , , , ,

As health systems acquire or partner with previously independent facilities to form Consolidated Enterprises, and implement a Shared Electronic Medical Record (EMR) system, they often consolidate legacy diagnostic imaging IT systems to a shared solution. Facilities, data centers, identity management, networking equipment, interface engines, and other IT infrastructure and communications components are also often consolidated and managed centrally. Often, a program to capture and manage clinical imaging records follows.

Whether the health system deploys a Vendor Neutral Archive (VNA), an Enterprise PACS, or a combination of both, some investment is made to reduce the overall number of imaging IT systems installed and the number of interfaces to maintain. An enterprise-wide radiation dose monitoring solution may also be implemented.

While much has been written on strategies to achieve this type of shared, integrated, enterprise-wide imaging IT solution, there are several other opportunities for improvement beyond this vision.

In addition to imaging and information record management systems, enterprise-wide solutions for system monitoring, audit record management, and data analytics can also provide significant value.

Systems Monitoring

Organizations often have some form of enterprise-level host monitoring solution, which provides basic information on the operational status of the computers, operating systems and (sometimes) databases. However, even when the hosts are operating normally, there are many conditions that can cause a solution or workflow to be impeded.

In imaging, there are many transaction dependencies that, if they are not all working as expected, can cause workflow to be delayed or disabled. Often, troubleshooting these workflow issues can be a challenge, especially in a high-transaction enterprise.

Having a solution that monitors all the involved systems and the transactions between them can help detect, prevent, and correct workflow issues.

Audit Record Management

Many jurisdictions have laws and regulations that require a comprehensive audit trail to be made available on demand. Typically, this audit trail provides a time-stamped record of all accesses and changes to a patient’s record, including their medical images, indexed by the users and systems involved.

Generating this audit trail from the myriad of logs in each involved system, each with its own record format and schema, can be a costly manual effort.

The Audit Trail and Node Authentication integration profile (ATNA), part of Integrating the Healthcare Enterprise (IHE), provides a framework for publishing, storing, and indexing audit records from different systems. It defines triggering events, along with a record format, and communication protocol.

Enterprises are encouraged to look for systems that support the appropriate actors in the ATNA integration profiles during procurement of new IT systems and equipment. Implementing an Audit Record Repository with tools that make audit trail generation easy is also important.

Data Analytics

Capturing and analyzing operational data is key to identifying issues and trends. As each system generates logs in different formats and using different methods, it often takes significant effort to normalize data records to get reliable analytics reports.

Periodic (for example, daily, weekly, or monthly) reports, common in imaging departments for decades, are often not considered enough in today’s on-demand, real-time world. Interactive dashboards that allow stakeholders to examine the data through different “lenses”, by changing the query parameters, are increasingly being implemented.

Getting reliable analytics results using data from both information (for example, the EMR and RIS) and imaging (for example, modalities, PACS, VNA, and Viewers) systems often requires significant effort, tools to extract/transform/load (ETL) the data, and a deep understanding of the “meaning” of the data.

Enterprise Insight

Implementing solutions that continuously and efficiently manage the health of your systems, the records accessed, and operational metrics are important aspects in today’s Consolidated Enterprise. Evaluating any new system as to their ability to integrate with, and provide information to, these systems is recommended.

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

dondennison Technology , , , , , , , ,

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

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

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

dondennison Healthcare IT , , , , , , , , , , , , , ,

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.