Patient Identity Management Maturity Model (PIM³) for Imaging Information Technology Systems

Abstract

In Consolidated Enterprises, there are often more than one set of patient identities or some amount of historic records, such as imaging exams that are still identified by more than one patient identity (also known as a Patient Identifier or Medical Record Number) per person. Information technology systems often need some capability to cross-reference records for the same patient so that the records are linked to the one, correct person. If not, it may create a risk for the patient. Historically, each independent facility or organization managed its own patient identity information, including the unique identifier/Medical Record Number. This can result in a fractured view of a patient’s records. To present a longitudinal, unified-view record of a patient, it is necessary to have functions to manage these multiple domains. Without this capability, multiple patient identity domains result in a broken imaging record for the patient and often prevents the discovery of, access to, and comparison of a patient’s imaging exams. Even worse, without a method to manage patient identity across records where more than one patient identity domain is involved, the records for two different people can be linked to one patient, resulting in a potentially serious risk for harm. This paper proposes a maturity model to assess and categorize the capabilities of different imaging information technology systems, such as Picture Archiving Communication and Archiving System, Vendor Neutral Archive, and other image management and viewing applications.

Introduction

In today’s Consolidated Enterprises, there are often more than one set of patient identities (collectively referred to as a patient identity domain) or some amount of historic records, such as imaging exams, that are still identified by more than one patient identity (also known as a Patient Identifier (ID) or Medical Record Number (MRN)) per person. Unless an information conversion process is conducted to index all historic records by a single patient identity domain, information technology (IT) systems will need some capability to cross-reference records for the same patient so that the records are linked to the one, correct person. If not, it may create a risk for the patient.

Historically, each independent facility/organization managed its own patient identity information, including the unique ID/MRN. Even within a single organization, MRNs may have been managed for different departments¹ or variants of the primary MRN value used (for example, by pre-fixing a text string). This can result in a fractured view of a patient’s records. This differs from most other industries, such as banking, where all records are tied to a single customer account or ID.

To present a longitudinal, unified-view of a patient record, it is necessary to have functions to manage these multiple domains. The inability for an imaging IT application to manage multiple patient identity domains results in a broken imaging record for the patient; this often prevents the discovery of, access to, and comparison of all of a patient’s imaging exams. Without a mature method to manage patient identity across records where more than one patient identity domain is involved, the records for two different people can be linked to one patient, resulting in a potentially serious risk for harm.

Due to the nature of the Digital Imaging and Communications in Medicine (DICOM) data format and the typical design of IT systems that manage this data, solutions need to consider that patient and other identifiers are persisted not only in a database, which is simple enough to update, but in each data file stored.

This paper proposes a maturity model to assess different imaging IT systems, such as Picture Archiving Communication and Archiving System (PACS), Vendor Neutral Archive (VNA), and other image management and viewing applications.² It will provide an overview of several different patient identity concepts related to imaging and advice for imaging informatics professionals on managing patient identities in IT systems.

Definitions

For the purpose of this paper, the following terms will be defined as follows:

• Assigning Authority—An entity within the healthcare enterprise that assigns identifiers.

• Consolidated Enterprise—An organization that once operated as multiple, independent organizations (each with one or more facilities offering healthcare services), but through merger, acquisition, or affiliation, now operates as a single enterprise.

• Patient—A person who has received care from a healthcare provider and has generated some information through examination, diagnostic tests, or treatment.

• Patient Identity (Patient ID)—A text value, often made up of a string of numbers, intended to represent the patient in an IT system, such as an Electronic Medical Record (EMR) system. Also known as an MRN.

• Patient Identity Domain—A logical collection of patient identities assigned by a single Assigning Authority, which is typically managed by a named instance of an information management system, such as an EMR.

• Record—Any information record managed in an IT system, including that for a patient, order, imaging exam, and result, that is associated with a patient identity.

Need for a Patient Identity Management Maturity Model for IT Systems

In the early days of information and imaging IT systems, the scope of data managed was for a single hospital. In the context of imaging IT, it was often a single department within a single hospital. As healthcare provider organizations consolidated into a single enterprise—through merger, acquisition, or affiliation—and IT systems became shared, it became necessary to manage patient records from different legacy organizations that were indexed by different patient identity domains.

As information and imaging IT systems vary in design based on the age of the system or the understanding and effort of the application developer, the ability to manage patient identity also varies. Determining whether a given (existing or to-be-purchased) IT system can support the patient identity requirements of an organization can often be a complex endeavor. It requires extensive definition of requirements and use cases, and analysis of technical information provided by each application vendor involved and under consideration. A well-defined model that establishes clear levels of maturity will make the determination of a system’s capability easier and less ambiguous. This paper proposes such a model.

Patient Identity Management Concepts

The following sections provide an overview of several concepts related to patient identity management. Understanding these concepts is necessary to understand the necessity of the various patient identity information management functions described in the proposed maturity model.

Patient Identity Domain

A patient identity domain is a logical concept, typically represented as a text string,³ that relates to one or more health information systems that generate patient identity values [1, 2]. In this paper, the term “domain” is used as a generic descriptor because different information standards (formal and ad hoc) use different terms. In Health Level Seven (HL7), the term used is Assigning Authority. In DICOM, the attribute used to persist the patient identity domain value is Issuer of Patient ID. It is considered a best practice to map the HL7 Assigning Authority value to the DICOM Issuer of Patient ID attribute in image management systems, like PACS and VNA systems. In some cases, people will refer to the name of the organization (for example, General Hospital) or system (EMR System X) as the domain, even though the text values used in IT systems will often differ from the informal names. A given organization or system may manage more than one patient identity domain as well.

A Patient is uniquely identified across systems through the combination of their Patient Identifier and Patient ID Domain values. It is important to note that the Patient ID domain value may not be globally unique. For example, if the value of “GENHOSP” is chosen by two organizations named General Hospital and end up in the same enterprise, one or both may need to be updated (in all systems that store patient information) to prevent a collision.

Patient Record Fracturing

When a person has more than one patient identity assigned, IT systems will typically treat the records assigned to each patient identity as completely different people. This results in a patient’s information being stored in separate “folders,” often making it difficult to discover and access the patient’s complete, longitudinal medical record (see Fig. 1).

Fig. 1.

Representation of different patient identifiers assigned to the same patient

If an image management system cannot effectively associate patient imaging records originating from the different patient ID domains, the patients will be treated as separate patients in the system. Consequently, studies associated with the different Patient IDs often cannot be viewed and compared at the same time.⁴ This issue puts patients at risk, because diagnosis or treatment decisions are made without this information being accessible. It can also lead to the added cost of repeating an imaging exam and in turn, an increase in patient anxiety and inconvenience.

Even within a single domain, a patient may be assigned more than one Patient ID. This scenario typically occurs when a clerk fails to find the original patient record and re-registers the patient (for example, when a patient arrives comatose to the hospital).

Patient Identity Collisions

Where more than one person is assigned the same patient identity, IT systems can associate records for them, generating a potential for harm. This scenario may occur within a patient identity domain management system through clerical error; however, it can also occur when records are generated and stored in IT systems using different patient identity domains or the same patient identity value for more than one person is coincidentally used. Those values are then stored in a system that does not qualify the patient identity by the domain. This issue becomes particularly evident during data migration and system consolidation.

HL7 Assigning Authority

A common method of communicating patient identity information is HL7 v2, which is a healthcare interoperability specification that allows transmission of trigger messages (such as patient admissions and discharges, orders, and results for tests) and includes specific fields for communicating identity. Though each message type typically includes at least one patient identity and domain value, the most common message type to communicate patient information is an Admission-Discharge-Transfer (ADT) message [3].⁵

HL7 v2.x ADT PID-3 Sequence

Per the HL7 standard, the message field normally used to communicate patient identity information (which may be one or more identities), is called PID-3 [4]. Some HL7 interfaces will put this information in other message fields, such as PID-2 or PID-4 [5].

HL7 FHIR

Fast Healthcare Interoperability Resources Specification (FHIR) is a new Representational state transfer-based web application programming interface (API) standard defined by HL7 [6, 7]. It uses pre-existing information schemas from mature HL7 standards but defines specific resources that can be queried for and retrieved. Many of the same challenges and solutions described throughout this paper apply when a FHIR-compliant API is used. FHIR, however, has adopted a more modern model for identity management, which includes additional concepts such as:

• Use: Specifies whether it is an official, normal, temporary, etc. identifier

• Period: Specifies the time in which an identifier is valid

• Type: Specifies what ‘kind’ of identifier it is. For example, 123:HospX is a departmental MRN, while 456:EMR is an enterprise ID

Use and Period are not available in DICOM, but Type is.

The patient resource is defined and explained in the FHIR standard [8]. The identifier attribute, which specifies the business identifiers, such as MRN for a patient, has data type Identifier. The Identifier data type is further defined in the FHIR standard as well [9].

Enterprise Master Patient Index

Though the concepts are not unique to healthcare, the use of an Enterprise Master Patient Index (EMPI)⁶ system is increasingly common in Consolidated Enterprises. These systems use demographic information, such as a patient’s name, date of birth, gender, and other information, to cross-reference patient identities from different domains. They typically get the source demographics and identity information through HL7 ADT interfaces or by entry via a user interface. Internal algorithms use configurable rules that match full or partial text string values within defined fields (for example, name, address, gender, birthdate) to link different patient identities to either an EMPI system-generated number, or a defined existing number (for example, a health number used in a public health system or similar regional organization) [10, 11]. The EMPI system can often be queried to discover other patient identities, along with the EMPI value, or this information can be “pushed” out via HL7 ADT (and potentially other types of) messages.

Increasingly, the health system’s EMR includes an EMPI module that is responsible for cross-referencing patient identities and providing the information to ancillary systems. On occasion, after applying rules that look for minimum thresholds of matching demographic information, the EMPI system will determine that two or more patient records may be the same person but cannot make a definitive determination. In these cases, an exception is typically thrown. Health Information Management (HIM) professionals manually review the information, potentially investigate other sources of data, and decide whether the records belong to one person or not.

In some cases, two previously independent organizations that used an EMPI merge create a scenario where two different EMPI values cross-reference two sets of patient ID domains. As each EMPI is itself a patient ID domain, this can be resolved by cross-indexing the historic EMPI values with the surviving (or new) EMPI domain value.

Patient Record Matching and Linking in the Imaging IT System

In addition to formal, managed systems for providing EMPI matching services, some applications will use basic patient demographic value matching to internally cross-reference records. For example, a PACS could use a comparison of patient demographics from two or more DICOM studies to conclude that the two exams are likely for the same patient, even if the Patient ID values differ. Experts debate the accuracy of such matching (compared with an EMPI system) but agree on the risk to patients if an incorrect match is made. Often these links are made only within the system that made the match and are not persisted in data communicated externally.

Prefixing (or Suffixing) of Patient ID Values to Avoid Collisions

Where IT systems are unable to qualify a patient identity—for example, because it does not store or make use of the HL7 Assigning Authority value to identity the patient identity domain and use it in combination with the patient ID value to uniquely identify the patient—a common strategy is used: prefixing or suffixing the Patient ID value. As an example, a Patient ID value of “12,345” from healthcare organization “ABC” could be altered to the value “ABC12345,” or “12345ABC” if a suffix is used. This approach only addresses the patient identity collision problem and does not solve the patient record fracturing problem. It also requires each organization to be assigned a unique value; if two organizations are assigned the value “ABC,” the potential for patient identity collisions still exists.

Patient ID Value “Padding”

In some cases, a Patient ID value may exist in systems as variants. The most common instance of this is when a Patient ID is found in one system as “1234567,” for example, but another as “0001234567.” The extra zeros are often called padding and are usually a result of the historic use of a legacy system which used fixed length fields (like those commonly found in old mainframe systems).

If the historic values were never converted to the core Patient ID value (which may be variable in length), it may be required to have a method to treat both values (with and without the padding) as equivalents. It may also be necessary to present the Patient ID as one or the other variant in the user interface (to provide the user with a consistent and expected value). Systems that support this equivalence often need to support coercion of the value to one of the variants when communicating with external systems. They frequently need to support reliable searching when either variant is entered by a user as well.

The same capabilities to deal with these equivalent variants may be needed to manage equivalents when prefixing or suffixing has occurred. For example, “1234567” should be treated as equivalent to “GH1234567” (the latter being the same as the former but prefixed with a set of text characters associated with a given organization, such as GH for General Hospital).

As Patient ID numbers increment, the string length can increase. For example, as the latest generated Patient ID value increments from 999999 to 1000000, the field length increases from six to seven digits. This detail is relevant when trying to use something as simple as the length of a number to alter the Patient ID—it may not be as simple as counting the digits and removing some at one end or the other.

Ensuring Correct Patient Identity Splits and Merges in a Multi-patient Identity Domain Environment

When operating in a multiple patient identity environment, one of the more complex challenges is to ensure that patient splits and merges, communicated through HL7 ADT messages, are applied correctly by the receiving system[3].⁷ Imagine a patient who has a dozen or more patient identities, all linked to an incorrect EMPI. Once the error is detected and corrected in the EMR (or other patient administration system), ADT messages are sent to any system connected by interface. Each receiving system must ensure that all records it manages, such as imaging studies in an image manager system, are no longer associated with any incorrect identities and are now associated with the correct identities.⁸

It is important to ensure that ADT messages are received and applied by the imaging IT system in the intended order. If this is not done properly, the records will likely either be incorrect or the record updates will fail.

Patient Record Coercion Systems

Many information and imaging IT systems have features to manipulate or otherwise coerce the values of record metadata, such as the values stored in DICOM attributes. This is sometimes called “tag morphing.” This technique can be used to update missing, incorrect, or outdated record metadata information with values that are current and accurate. The same technique can be used to apply an Issuer of Patient ID attribute value, or to conditionally prefix or suffix a Patient ID (or other attribute) with a defined text string to ensure uniqueness, or even to replace one value with another. These features can be very useful when an imaging management system needs to communicate and share data with systems that require certain attribute values to match defined standards. For example, if a PACS or VNA is communicating with a workstation that has no ability to cross-reference a patient’s imaging studies that were acquired using different Patient IDs, it may be necessary to coerce the Patient ID values of the exams sent to the workstation to a common and accepted Patient ID value. This way, the workstation can treat all the exams for the patient as part of one “folder” and can safely allow side-by-side exam comparison in a viewer application.

Applications that may be employed to apply this type of patient identity information coercion in DICOM records and HL7 messages include interface engines, the EMR (as part of an interface), departmental information and imaging management systems, and workflow engines, among others.

Great care must be taken whenever data coercion affecting identifiers is implemented. Often, the data mapping rules consider typical patterns but may not apply the desired transforms when atypical data is encountered. In many instances, there is limited traceability in the records themselves, but perhaps some in system logs, as to when or what data coercion has been applied.

Reconciling/Localizing Patient Records

When patient records, such as imaging studies, are created by another organization that uses a different patient identity domain and procedure codes and descriptions, it is typically necessary to replace the existing, original values for some attributes with ones used within the importing organization’s systems.⁹ This process is occasionally called reconciling or localizing.

The IHE integration profile Import Reconciliation Workflow (IRWF.b)¹⁰ provides further details on recommended best practices for this process [12]. As well, the new IHE Import and Display of External Priors (IDEP) integration profile, in development at time of publication, is another to consider when planning implementations. It uses the part of IRWF.b logic with additional requirements to handle reports, coercion, and retention.

DICOM Attributes Related to Patient Identity

Several DICOM attributes are related to patient identity:

• Patient ID (0010,0020)—Primary identifier for the patient.

• Issuer of Patient ID (0010,0021)—Identifier of the Assigning Authority (system, organization, agency, or department) that issued the Patient ID.

• Issuer of Patient ID Qualifiers Sequence (0010,0024)—Used if the Patient ID is an OID.

• Other Patient ID Sequence (0010,1002)—A sequence of identification numbers or codes used to identify the patient (and optionally the type of identifier), which may or may not be human readable, and may or may not have been obtained from an implanted or attached device such as an RFID or barcode. One or more items are permitted in this sequence.

• Other Patient IDs (0010,1000) [Retired]—This attribute has been retired from the DICOM standard and replaced by the Other Patient IDs Sequence attribute. The Other Patient IDs attribute does not specify an issuer for each patient identity (or type), which could lead to implementation issues. There may be systems in use that rely on this attribute.

Updates to DICOM Files

Depending on the design of a given imaging IT system, the values within the DICOM files may or may not be updated when there is a change to an attribute. Many systems update this information in the database when the update is received (or applied by a user through the system’s data correction UI), and only update the DICOM data when it is communicated outside the system.

Original Attribute Sequence DICOM Attribute

Though not directly related to patient identity management, the DICOM attribute Original Attributes Sequence (0400,0561) can be a valuable data element to understand. This attribute is intended to provide a field, whereby original patient information can be stored when it is necessary to reconcile/localize a patient’s imaging records to use another organization’s information. For example, if a patient imaging record (exam) is imported by an organization, several of its patient-related DICOM attribute values, including the Patient ID, are overwritten with new values generated by the patient administration system of the importing organization. This ensures the record will be linked to other records that may be generated at the importing organization. To avoid simply overwriting the original values, the Original Attributes Sequence value is populated with the original values, for future reference.

This attribute can also be useful when normalizing patient demographic information (for example, using an extract from the EMR) during a data migration, if it is desirable to preserve the original attribute values in the DICOM objects.

Additional Resources

Here are some additional resources related to patient identity and demographics management, in general (not specific to imaging IT systems):

• HIMSS Patient Identity Integrity Toolkit [13]

• Patient Demographics Data Quality (PDDQ) Framework [14]

Advice

If evaluating the ability of an imaging IT solution to manage patient identity information, it is advisable to consider the following:

• Have a Strategy. It is important to have a clear vision and strategy for system and data consolidation within the enterprise. Imaging IT professionals should understand their organization’s policies, procedures, governance, and staffing responsible for managing patient identities and other demographics.

• Know your Enterprise. Knowing how patient identity information is managed within an enterprise helps imaging IT professionals define and implement new solutions, as well as troubleshoot any inconsistent patient records. Having a good understanding of how patient identities are managed within an organization, and within the imaging IT applications used within an enterprise, is helpful when establishing cross-enterprise data exchange.

• Know the Concepts. Understanding the fundamentals of patient identity management is important for imaging IT professionals. Even if the current state of the health system enterprise is a single patient identity domain, this can change with an acquisition or merger.

• Assess Maturity of All Potentially New Systems. To future-proof against any potential change to the desired state of patient identity management, purchasing and implementing imaging IT systems that can support a variety of scenarios will help provide solutions to address challenges that arise from these changes.

Patient Identity Management Maturity Model (PIM³) for Imaging Information Technology Systems Summary

As shown in this paper, patient identity management concepts and the associated information models and data standards can be complex to fully understand. As imaging informatics professionals depend heavily on patient identity management strategies and methods for responsible record management, they need to understand not only the theory and best practices of patient identity management, but to know exactly how patient identity is managed within all the imaging (and associated) IT systems they use and for which are responsible.

This knowledge of how imaging IT systems manage patient identity is important not only in ensuring quality record management in daily operations but also during the evaluation of potential new imaging IT systems that their organization may procure. To assist in quantifying patient identity management capabilities within an imaging IT system, a tiered maturity model is proposed.

The intent is that the proposed model could be used both by buyers/operators of imaging IT systems to specify the level of capability they need in a potential new system, and for industry to specify the level of capability supported in a given system. This clear specification by both parties is intended to simplify the evaluation of imaging IT systems while making needs and capabilities much more quantifiable.

The use of tiers of capability was selected as many of the more complex and flexible capabilities necessary in an imaging IT system depend on more basic capabilities to be in place.

It is important to note that not all imaging IT systems may require the most advanced capabilities defined in the proposed model. For example, some subspecialty mini-PACS may not require advanced functions when operated in a single department or used at a single facility. Imaging records forwarded from this type of system to one that has capabilities to achieve a higher tier in the proposed model, such as an Enterprise PACS or VNA, may be an effective strategy to comply with an organization’s policies and meet their objectives.

The proposed model defines numeric categories (tiers) of capability, from zero (0) to five (5). The base numeric tier is defined based on a clearly defined and measurable level of patient identity management capabilities. The lower tiers define capabilities that are more appropriate for basic needs and simple patient identity management (for example, a single patient identity domain), while the higher tiers define capabilities to solve more complex enterprise-wide or cross-enterprise patient identity management challenges.

Several of the tiers (1 through 4) have some defined conditional patient identity management capabilities that may be required from, or available in, an imaging IT system. These related capabilities are designated with a “+” in Fig. 2 and Table 1. This approach is used to minimize the number of tiers in the proposed model (reducing complexity) without making the conditional capabilities mandatory for achieving a maturity level.

Fig. 2.

Summary of the proposed Patient Identity Management Maturity Model for Imaging IT Systems

Table 1.

Table of proposed Patient Identity Management Maturity Model for Imaging IT Systems with detailed descriptions for each level of maturity [15, 16]

Level	Description	Notes
0	• Support for the Patient ID DICOM attribute to identify the patient to whom the record belongs • No ability to use a Patient Identity Domain value as a qualifier for the Patient ID • No MPI cross-reference support • No ability to prefix or suffix the Patient ID value to prevent Patient ID collisions • May or may not support updates to the patient information from HL7 messages	• Systems at this level assume a single patient identity domain per record, and do not qualify the patient ID value; therefore, if patient records from different domains are co-mingled in a system, there is the potential for a patient identity collision
1	• No ability to use a Patient Identity Domain value as a qualifier for the Patient ID • No MPI cross-reference support • Able to conditionally prefix or suffix the Patient ID DICOM attribute value using a value (text string) defined for an organization/domain/facility to prevent Patient ID collisions • Support for updates to patient information from HL7 messages based on the original Patient ID	• Prefix or suffix value per domain/organization/facility is predefined and assigned based on rules (for example, prefix value added for all DICOM data from a list of Application Entity Titles (AETs)
1 +	• Same as Level 1, but also includes the capability to strip the prefix or suffix value when communicating with systems that relies on the original source Patient ID (not the prefixed/suffixed Patient ID value) like the EMR (this applies in DICOM and HL7 communication, but also when sharing the Patient ID value through an API, such as used in desktop integrations)	• When prefixing/suffixing a patient ID value and communicating with other IT systems that use patient ID values that do not include the prefix/suffix value, the application will need to strip out the text string in messages and records exchanged; if not the prefixed/suffixed patient ID will be treated as a different patient that the one that is not prefixed/suffixed
2	• Able to internally qualify the Patient Identity Domain using Assigning Authority value from HL7 messages (such as ADT) or by assigning a predefined value, based on the source system (e.g. Calling DICOM AET) of the data (when HL7 ADT or other messages are not available) • No MPI cross-reference support	• No need to prefix/suffix Patient ID
2 +	• Same as Level 2, but able to provide the Assigning Authority value in the Issuer of Patient ID DICOM attribute for both C-FIND and C-STORE transactions (for example, including the metadata in the DICOM object headers of transmitted data)	• Provides domain-qualified patient identity info through DICOM to external systems
3	• Able to persist and use a single EMPI value to cross-reference records with different Patient ID values, typically provided in HL7 ADT messages	• The EMPI value should be qualified with its own unique domain value, as when different organizations operating an EMPI consolidate their IT systems or exchange data, there may be more than one EMPI in use • Patient record splits and merges must associate records with the correct EMPI value, not just the correct Patient ID
3 +	• Same as Level 3, but able to discover the EMPI value using an on-demand query, including methods such as HL7 v2 or Web service, per the IHE Patient Identifier Cross-Referencing (PIX) v2 and v3 integration profiles, or the IHE Patient Identifier Cross-Reference for Mobile (PIXm) integration profile, which uses FHIR-based transactions	• It is not always practical to have all patient identities be provided to all IT systems through an HL7 ADT interface; it may be necessary to “look up” this information in an integrated system when needed (for example, as part of a query for all a patient’s records across organizational boundaries)
4	• Able to support management and cross-referencing of multiple patient identities, including one or more EMPI values, defined by their domain and Patient ID	• Where a patient may have several identities within an enterprise (or across enterprises that are sharing data), it may be necessary for an IT system to persist and manage not only one local patient ID and an EMPI value, but multiple patient identities
4 +	• Same as Level 4, but the ability to use defined rules to coerce the Patient ID and Issuer of Patient ID values in DICOM communication, as well as the Patient ID and Assigning Authority values in HL7 communication, when exchanging information with external systems that are unable to manage multiple patient identity domains • Able to conditionally populate the Other Patient IDs Sequence DICOM attribute with all or select (based on defined rules) patient identities when transmitting imaging exam records • Able to conditionally parse the Other Patient IDs Sequence DICOM attribute and persist all or select (based on defined rules) patient identities when receiving imaging exam records that contain this attribute	• It is often necessary to seek IT systems with this level of capability when integration and data exchange with other IT systems that do not have as high a maturity is required; the mature system is required to alter patient identity information in shared records and messaging so that it matches a simplified model, which may mean coercing all information to a single patient identity
5	• Able to define equivalences across domain identifiers, such as having the existence of a prefix defined value in a Patient ID be treated equivalent to a defined Assigning Authority value or treating a historic Assigning Authority value as equivalent to a new value • Able to define equivalences where Patient ID values may contain leading or trailing zeros (or other values), or not. For example, the ability, by rule, to treat “000012345” and “12345” as equivalent	• In complex enterprises that have been consolidating (and/or replacing) IT systems for some time, more than one patient identity management strategy may have been employed; in these organizations, not all records may be cleanly and consistently managed, or be managed in one system, requiring some logic to define equivalent domain representations • The need for this level of maturity may be avoided if all historic and inconsistent data is converted to the new standard for patient identity domain representation, but this is not always possible and does not always address historic data imported after the conversion

As an example of its use, a healthcare provider looking to buy and implement a new imaging IT system could use the model to determine that their needs (current and near-term future) correspond with level 3+ . An imaging IT solution vendor could respond that their system supports level 4, meaning that the system can address the health system’s needs. Furthermore, another vendor could specify their system meets only level 3 (not 3+). The healthcare provider would have to assess the impact of choosing the solution from the second vendor when the conditional capabilities defined in 3+ (“EMPI Discovery by Query”) would not be available.

Visual and tabular summaries of the proposed model are provided in Fig. 2 and Table 1.

Each level of maturity requires the IT system to support all the capabilities described for the defined level, as well as the capabilities for all lower levels. The bottom row in the illustration above denotes the level of scale of system communication that can generally be supported with the maturity level above it. The “+” extensions to each maturity level generally relate to dealing with, or persisting, patient identity information when communicating with external systems.

Declarations

Conflict of Interest

The authors declare that they have no conflict of interest.