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 (PIM³) 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.

System	RIS	DMWL & Modality	PACS
Impact	During exam scheduling & patient communication	During imaging exam acquisition	During 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.

Standard	Field/Attribute	Notes
HL7 v2	PID.5 Patient Name	As 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 FHIR	HumanName	FHIR 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).
DMWL	Patient’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 Objects	Patient’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).

Code	Display
A	Assigned
B	Birth name
BAD	Bad Name
C	Adopted Name
D	Customary Name
F	Fathers Name
I	Licensing Name
K	Business name
L	Official Registry Name
M	Maiden Name
MSK	Masked
N	Nickname
NAV	Temporarily Unavailable
NB	Newborn Name
NOUSE	No Longer To Be Used
P	Name of Partner/Spouse
R	Registered Name
REL	Religious
S	Pseudonym
T	Indigenous/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.