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.

Article: Imaging IT trends to watch in 2023

dondennison Healthcare IT , , , , , , ,

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.

Button with the word Adapt on it

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.

There’s a New Sheriff in Town: When Enterprise IT Takes Over Imaging IT

dondennison Change Management , , , , , ,

When IT professionals from Radiology and other image-generating departments merge with the enterprise IT team that provides IT infrastructure and support for enterprise-wide solutions, employee angst and culture friction can occur.

The same thing can happen when imaging IT teams historically working at different sites are merged to a single group, or when imaging informatics professionals (IIPs) from different healthcare service lines, like Radiology and Cardiology, are put into the same team.

In this paper published in Journal of Digital Imaging (JDI), all these topics are covered, along with things to consider when managing (or undergoing) these team consolidations, and tips for success.

Adapt

Patient Identity Management in Imaging IT Systems: A Proposed Maturity Model

dondennison Healthcare IT ,

Over the years, I have found that many working in imaging informatics understand the basics of how patient identity is managed in healthcare information systems. In today’s Consolidated Enterprises, where the historic imaging exam data for a given person may be indexed by many different patient identities, and perhaps cross-referenced by an Enterprise Master Patient Index (EMPI), ensuring that all a patient’s records are accurately associated with the correct Patient Identity (ID) requires understanding of the information models and values that may be in use at the enterprise. Along with the strategy and vision for how Patient IDs will be managed in future.

New data acquired in other enterprises continues to come into an enterprise’s imaging IT systems. From data migration associated with system consolidation (for example, as part of organizational merger or acquisition activities) to programs that involve data exchange—such as importing outside exams prior to appointments, teleradiology, or the sharing of systems with affiliates—ensuring that your imaging IT systems can safely and reliably handle all the potential complexities is important.

Patient ID Management Maturity Model (PIM3)

In the JDI article, “Patient Identity Management Maturity Model (PIM3) for Imaging Information Technology Systems” (Note: access to the Journal of Digital Imaging, such as that provided by SIIM membership, is required) a maturity model for assessing both an enterprise’s needs (today and potentially in future) and the capabilities of a given imaging IT system is proposed.

The intent is to establish a simple, hierarchical model by which both healthcare system operators and vendors can easily match needs with capabilities.

In addition to the proposed model, the paper provides an overview of many patient identity management concepts, data standards, along with challenges and potential methods of addressing them. Those interested in simply learning more about patient ID management in imaging informatics and IT systems may find the paper informative.

MIIT21 – Learn About Imaging Informatics & Earn 10 CE Credits!

dondennison Healthcare IT ,
@MIIT_Canada | #MIIT21

Medical Imaging Informatics and Teleradiology (MIIT) is once again virtual, but the format of this year’s meeting is new. Instead of the traditional full-day of content, MIIT21 will be organized into half a day’s content available in spring and again in the fall. Sessions will be pre-recorded, with a live faulty roundtable for each session.

There will also be a live Keynote session on Thu 25-Mar-2021 at 4 pm ET. Dr. Rasu Shrestha, Chief Strategy and Transformation Officer at Atrium Health, will give a talk titled “Confronting Reality – Reimagining the Next Normal for Healthcare”.

The live keynote and two faculty roundtables will be recorded and available to registered attendees after they are complete.

Our speakers will cover topics such as AI and Fairness, updates in data standards, updates on gender in HL7, AI deployment, research programs in data science, global health outreach, structured reporting in Enterprise Imaging, and an expert panel on the progress and vision of Diagnostic Imaging Repositories (DIR) in Canada.

The full program can be found here.

Register today by clicking on the “Register Now” button on the main MIIT webpage.

As Co-chair, I also want to thank our generous sponsors. Without their support, we would be unable to deliver this important educational content.

MIIT is accredited by the Continuing Education Credit Approval Program (CECAP). Registered attendees must log in and review all the MIIT content to earn 10 Category A CE Credits.

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.

MIIT20 – Don’t Miss This Year’s Program!

dondennison Uncategorized

Now Virtual! No Travel! CE & CME Credits!

See updated info in this post!

Medical Imaging Informatics and Teleradiology (MIIT), the one-day educational meeting on imaging informatics, returns to beautiful Liuna Station in Hamilton, ON on Friday May 15, 2020. MIIT has been going for 15 years and this year has a great program with speakers from leading Canadian and U.S. institutions speaking on a range of timely topics, including hot topics like AI, multimedia reporting, change management, and building effective teams, as well as a panel discussion.

We are excited to have Drs. Tessa Cook from UPenn, Vamsi Narra from BJC, Cree Gaskin from UVa, Les Folio from the NIH, Adam Prater from Emory, as well as Michael Toland from UMMS and Dr. Christian van der Pol and Ted Scott from HHSC, providing talks in person or remotely, along with Kevin O’Donnell providing an update on the DICOM standard and MIIT’s own Britt Tomlin providing a talk on the Alberta province-wide Connect Care EMR project.

Program

Check out the full program here.

Sponsorship

Information on sponsoring MIIT is here.

Registration

To register as an attendee or sponsor, click here. All prices are in CAD$.

Standard Physician registration are $200, and healthcare professionals are $150.

Early-bird registration has two deadlines with discounts for early registration. The dates and discounted rates are:

  • Physicians: By 25-Mar-2020, $150; By 27-Apr-2020, $175
  • Healthcare Professionals: By 25-Mar-2020, $100; By 27-Apr-2020, $125

A group discount rate is available to help teams attend.

  • 3-4 registrants: 10% discount
  • 5+ registrants: 20% discount

The above discounts may be applied to the early-bird rates, resulting in big savings for groups that register early.

The registration fees make MIIT very affordable, especially considering the quality of speakers and talks available in a great, easy-to-get-to venue.