This Appendix has been updated by Trial-Implementation text that is included below in section E.3.

Appendix E: Patient Identifiers in HL7-based IHE Profiles

The Health Level Seven Standard (HL7) uses data type CX to express various identifiers, including the Patient ID in the third field of the PID segment. We discuss here how IHE IT Infrastructure expects the CX data type to be populated in the PID-3-Patient Identifier List fields of messages that it defines.

Requirements for populating the elements of PID-3-Patient Identifier List vary slightly, depending on what actor is originating the transaction in which the PID segment is sent. If the Patient Identifier Cross-reference Manager is the source of the PID segment, the requirements (specifically, with respect to populating the Assigning Authority subcomponents) are more rigorous than otherwise.

PID-3-Patient Identifier List permits multiple occurrences of the CX data type. Data type CX contains 8 components as shown below. This structure allows expression of the value and context for each identifier that the system knows.

Table E-1: Components of HL7 Data Type CX

Cmp	Len	DT	Opt	Tbl	Name
1	15	ST	R		ID
2		ST	O		Check digit
3		ID	O	0061	Code identifying the check digit scheme employed
4	227	HD	R		Assigning authority
5		ID	O	0203	Identifier type code
6		HD	O		Assigning facility
7		DT	O		Effective date
8		DT	O		Expiration date

Adapted from the HL7 Standard, Version 2.5

Each occurrence of PID-3-Patient Identifier List contains, at a minimum, an identifier value in Component 1 and an assigning authority in Component 4. The assigning authority unambiguously provides the context for the identifier. It is also common practice to provide an identifier type code in Component 5, but this is not required by IHE in the context of the PIX transactions [ITI-8], [ITI-9], and [ITI-10]. Other components are optional and will not be discussed here; implementers may refer to HL7 Version 2.5 for more information.

Component 1 of Data Type CX, ID , is of data type ST. This data type allows a free text value of up to 15 characters. As implemented in HL7 Version 2.5. Prior to Version 2.5, HL7 did not specify the length of individual components. Although the profiles in IHE-ITI are based Versions 2.3.1 and 2.4 of HL7, they use the component length constraints provided by Version 2.5 to support forward compatibility.

Component 4 of Data Type CX, Assigning Authority , is of data type HD. This data type contains 3 components that, when implemented at the component level, become subcomponents of Component 4. The requirements for the subcomponents of Component 4 vary by actor.

E.1 Patient Identifier Cross-reference Manager Actor Requirements

The Patient Identifier Cross-reference Manager is expected to have access to complete internal and external identifier information for the Assigning Authority of the patient identifier. To facilitate interoperability, it is required that the Patient Identifier Cross-reference Manager populate all subcomponents of the Assigning Authority component. The usage of these subcomponents will be explained in the examples below.

This requirement applies to the response portion of the PIX Query [ITI-9] and PIX Update Notification [ITI-10] transactions.

Table E-2: Usage of HL7 Data Type CX by the PIX Manager Actor

Cmp	Sbc	Len	DT	Opt	Tbl	Name	Conditionality predicate
1		15	ST	R		ID
2			ST	O		Check digit
3			ID	O	0061	Code identifying the check digit scheme employed
4		227	HD	R		Assigning authority	Subcomponent 1 must refer to the same entity as Subcomponents 2 and 3.
4	1	20	IS	R	0363	Namespace ID
4	2	199	ST	R		Universal ID
4	3	6	ID	R	0301	Universal ID type
5			ID	O	0203	Identifier type code
6			HD	O		Assigning facility	If all three subcomponents are populated, they must refer to the same entity.
6	1		IS	O	0300	Namespace ID
6	2		ST	C		Universal ID	Populated if, and only if, Subcomponent 3 is populated.
6	3		ID	C	0301	Universal ID type	Populated if, and only if, Subcomponent 2 is populated
7			DT	O		Effective date
8			DT	O		Expiration date

IHE specifies that the Patient Identifier Cross-reference Manager must populate all 3 subcomponents of Component 4. The following rules apply:

Subcomponent 1 of Component 4, Namespace ID , is of data type IS. HL7 specifies that when valued in the Patient ID field, the value in this subcomponent be a code taken from user-defined Table 0363, Assigning Authority . Version 2.5 of HL7 provides suggested values for assigning authorities in various local jurisdictions, such as USSSA for U.S. Social Security Administration. Sites may add values to this table, but for interoperability must ensure that added values (and meanings) are agreed upon by all communicating systems.

Subcomponent 2 of Component 4, Universal ID , is of data type ST. This subcomponent contains a value from either a known external domain or a specified internal domain. The domain is given in Subcomponent 3.

Subcomponent 3, Universal ID Type , is of data type ID. This subcomponent contains a code taken from HL7 Table 0301, Universal ID Type . Table 0301 contains values for various known external identifier domains such as DNS (Internet dotted name) and ISO (International Standards Organization Object Identifier, or OID), as well as the values L, M, and N to permit the use of internal identifier domains.

Subcomponent 1 must refer to the same entity as Subcomponents 2 and 3.

E.1.1 Other actor requirements

The PID segment may also appear in messages generated by other IHE actors, including the Patient ID Cross-reference Consumer and the Information Source. These actors must also populate the Assigning Authority.

However, IHE specifies that they need not populate all three subcomponents of Assigning Authority. They must populate either Namespace ID (an entry from a user-defined table), or Universal ID and Universal ID Type (allowing the use of an externally defined identifier scheme).

This requirement applies to the Patient Identity Feed [ITI-8] transaction and to the query portion of PIX Query [ITI-9]. This requirement does not apply to the response portion of [ITI-9] nor to PIX Update Notification [ITI-10].

Table E-3: Usage of HL7 Data Type CX by other IHE Actors

Cmp	Sbc	Len	DT	Opt	Tbl	Name	Conditionality predicate
1		15	ST	R		ID
2			ST	O		Check digit
3			ID	O	0061	Code identifying the check digit scheme employed
4		227	HD	R		Assigning authority	If all three subcomponents are populated, they must refer to the same entity.
4	1	20	IS	C	0363	Namespace ID	Must be populated if Subcomponents 2 and 3 are not populated.
4	2	199	ST	C		Universal ID	Must be populated if Subcomponent 1 is not populated. Populated if, and only if, Subcomponent 3 is populated.
4	3	6	ID	C	0301	Universal ID type	Must be populated if Subcomponent 1 is not populated. Populated if, and only if, Subcomponent 2 is populated.
5			ID	O	0203	Identifier type code
6			HD	O		Assigning facility	If all three subcomponents are populated, they must refer to the same entity.
6	1		IS	O	0300	Namespace ID
6	2		ST	C		Universal ID	Populated if, and only if, Subcomponent 3 is populated.
6	3		ID	C	0301	Universal ID type	Populated if, and only if, Subcomponent 2 is populated.
7			DT	O		Effective date
8			DT	O		Expiration date

The definitions of the subcomponents of Component 4 are as given above for the Patient Identifier Cross-reference Manager. If all three subcomponents are defined, Subcomponent 1 must refer to the same entity as Subcomponents 2 and 3.

E.1.2 Examples of use

Metropolitan Medical Center treats a patient, Jane Smith, for whom 3 identifiers are known. (For this example, assume that the HL7 V2 default delimiters are in use: | for field separator, ^ for component separator, ~ for repetition separator and & for subcomponent separator.)

E.1.3 Data sent by source systems

The source systems provide data to the Patient Identifier Cross-reference Manager. These data are sent either in a Patient Identity Feed [ITI-8] transaction or in response to a PIX Query [ITI-9].

Patient Smith’s Social Security number is 999-99-4452 . This number is assigned by the U.S. Social Security Administration.

The ADT system sends the Social Security number at registration, in an occurrence of PID-3-Patient Identifier List that looks like this:

999-99-4452^^^USSSA

Note that only Subcomponent 1 of Assigning Authority is assigned here, while Subcomponents 2 and 3 are left empty.

Patient Smith’s medical record number is 9990-99497 . This number is assigned by Metropolitan Medical Center, for which no external identifier is known. Metropolitan Medical Center incorporates the Namespace ID 99MMC for the medical record numbers it assigns.

The ADT system sends the medical record number at registration, in an occurrence of PID-3-Patient Identifier List that looks like this:

999099497^^^99MMC

Note again that only Subcomponent 1 of Assigning Authority is assigned here.

Patient Smith’s medical insurance number is 99998410 . This number is assigned by MLH Life & Casualty Company, whose Internet domain name is www.mlhlifecasualty.com .

Implementers should take into account the possibility that, as with any domain identifier, Internet domain identifiers – either fully qualified domain names (FQDNs) or IPv4 or IPv6 addresses – are liable to change.

The billing system sends the medical insurance number in an occurrence of PID-3-Patient Identifier List that looks like this:

99998410^^^&www.mlhlife.com&DNS

Note that only Subcomponents 2 and 3 of Assigning Authority are assigned here. Also note the value DNS in the third subcomponent of Component 4 to indicate an Internet domain name.

E.1.4 Data sent by the Patient Identifier Cross-reference Manager

The Patient Identifier Cross-reference Manager implements HL7 Table 0363, Assigning Authority , by incorporating the values in HL7 Version 2.5 as well as the values 99MMC for Metropolitan Medical Center and 99MLHLIFE for MLH Life & Casualty.  It also includes a known ISO Object Identifier for the Social Security Administration, 1.2.mm.nnnnn.555.6666 . The use of 99

to preface these codes is not mandated by HL7, but reflects the practice directed by Chapter 7 of HL7 Version 2.5 for specifying local coding system values.

This OID is fictitious. The real OID for the SSA should be substituted here.

To send the identifiers in PID-3-Patient Identifier List , the Patient Identifier Cross-reference Manager builds and concatenates them as follows.

In the first occurrence, the Social Security number is sent in the first component, as well as the known internal and external values for SSN assigning authority in the fourth component. Note the value ISO in the third subcomponent of Component 4 to indicate an ISO Object Identifier.

999-99-4452^^^USSSA&1.2.mm.nnnnn.555.6666&ISO

In the second occurrence, the medical insurance number is sent in the first component, as well as the known internal and external values for insurance number assigning authority in the fourth component.

99998410^^^99MLHLIFE&www.mlhlife.com&DNS

In the third occurrence, the medical record number is sent in the first component, as well as the known internal and external values for MRN assigning authority in the fourth component. Note that no external value is known for MRN assigning authority, so the HIS repeats the internal value as an external value and uses the value L in the third subcomponent of Component 4 to indicate a locally assigned value.

999099497^^^99MMC&99MMC&L

In sending all values in a PIX Update Notification [ITI-10] transaction, the Patient Identifier Cross-reference Manager concatenates the three PID-3-Patient Identifier List values using the repetition separator:

|999994452^^^USSSA&1.2.mm.nnnnn.555.6666&ISO~99998410^^^99ABCLIFE&www.abclife.com&DNS~999099497^^^99MMC&99MMC&|

E.2 HL7 V3 II Data Type

The Health Level Seven Standard Version 3 (HL7 V3) uses data type II to express an identifier that uniquely identifies a thing or object (see HL7 Version 3 Standard Data Types), including medical record number or other patient identifiers. We discuss here how IHE IT Infrastructure profiles the use of II data type to express patient identifiers in HL7 V3 messages and HL7 V3 CDA Document Templates defined or referenced in this Technical Framework. In the following text of this section, all requirements for the II data type are specified solely in the context of patient identifier expression.

Since IHE adds additional constraints to the II data type, requirements for populating its elements vary slightly, depending on what actor is originating a transaction (or create a CDA document), in which Patient ID is expressed. If the Patient Identifier Cross-reference Manager is the source of the Patient ID in a message, the requirements (specifically, with respect to populating the assigningAuthorityName elements) are more rigorous than otherwise.

The IHE IT Infrastructure Technical Framework adds constraints to the II data type for Patient ID expression in HL7 V3 messages or CDA documents, in order to maintain compatibility with the explicit relationship between a Patient ID Domain (assigning authority) and a Patient ID issued in the Domain present in the HL7 V2 CX data type. In HL7 V2 messages defined in the IHE IT Infrastructure Technical Framework, Patient ID is expressed in the form of an identifier value (CX.ID) issued in a domain (CX.AssigningAuthority) (see Section E.1). Even though HL7 V3 provides additional mechanisms for an explicit expression of the key concept of Patient ID Domain (via scoping organizations), the constraints added to the II data type in this section enable a seamless interoperability among HL7 V2 messages, HL7 V3 messages, as well as CDA documents, which may participate in the same IT Infrastructure Profile.

At the same time, it is also important to represent the RIM-based association between assigning authority and patient identifiers, which is expected by systems using the rich semantics of the RIM. In order to achieve that IHE imposes several constraints regarding patient IDs on the HL7 V3 models used in IHE transactions:

1. Identifiers for the patient are class attributes of a specific role, and never of the Person class of the patient.
2. When the Patient role is scoped by a Provider organization, only patient IDs assigned by the provider organization are allowed in the Patient class, the root element of the patient IDs shall match the root element of the provider organization ID, and the provider organization ID shall have no extension element.
3. When any other role associated with the Person class of the patient is scoped by an organization, the root element of the role IDs shall match the root element of the scoping organization ID, and the scoping organization ID shall have no extension element.
4. A receiver of an HL7 v3 message shall consider the IDs in all roles associated with the Person class of the patient as valid patient IDs.
5. A receiver of an HL7 v3 message shall not be required to maintain the various roles associated with the Person class of the patient, as long as, when becoming a sender, it can appropriately send all relevant patient IDs according to the requirements of a particular transaction.

E.2.1 Patient Identifier Cross-reference Manager requirements

The Patient Identifier Cross-reference Manager is expected to have access to complete information for a Patient ID value and its issuing Patient ID Domain (assigning authority). To facilitate interoperability, it is required that the Patient Identifier Cross-reference Manager provide all this information in an instance of II the data type to express Patient ID. Table E-2.1-1 specifies the requirements of the II data type to the Patient Identifier Cross-reference Manager.

Table E.2.1-1: Usage of HL7 V3 II Data Type by the PIX Manager

Name	Type	Opt	Name
Root	OID	R	An ISO OID of the Patient ID Domain (assigning authority) that guarantees the global uniqueness of the patient identifier.
Extension	ST	R+	A character string as a unique identifier within the scope of the Patient ID Domain (assigning authority) represented by the identifier root.
assigningAuthorityName	ST	R+	A human readable name or mnemonic for the assigning authority. The Assigning Authority Name has no computational value. The purpose of an Assigning Authority Name is to assist an unaided human interpreter of an II value to interpret the authority. Note: no automated processing must depend on the assigning authority name to be present in any form.
Displayable	BL	O	Specifies if the identifier is intended for human display and data entry (displayable = true) as opposed to pure machine interoperation (displayable = false).

IHE specifies that the Patient Identifier Cross-reference Manager must populate both elements root and extension for Patient ID Domain and Patient ID value, respectively, and element root must be an ISO OID. If the same patient identifier is populated in a HL7 V2 message, element root and extension shall correspond to CX.4.2 and CX.1, respectively, and CX.4.3 shall be ISO (see Section E.1).

In addition, IHE requires that the Patient Identifier Cross-reference Manager populates element assigningAuthorityName. Though there is no additional requirement for the data type of this element than a text string in a HL7 V3 message or CDA document, it shall be the same value as populated in CX.4.1, if the actor participates in transactions of both HL7 V3 and HL7 V2 messages. In this case, element assigningAuthorityName shall contain a value of HL7 V2 data type IS, a code taken from user-defined Table 0363, Assigning Authority, see Section E.1.

E.2.2 Other actor requirements

The patient identifier information may also appear in HL7 V3 messages or CDA documents generated by other IHE actors, including the Patient Identifier Cross-reference Consumer, the Patient Information Source, XDS Document Source. Table E.2.2-1 specifies requirements for these actors when populating a value of the II data type to express a patient identifier.

Table E.2.2-1: Usage of HL7 Data Type CX by other IHE Actors

Name	Type	Opt	Name
Root	OID	R	An ISO OID of the Patient ID Domain (assigning authority) that guarantees the global uniqueness of the patient identifier.
Extension	ST	R+	A character string as a unique identifier within the scope of the Patient ID Domain (assigning authority) represented by the identifier root.
assigningAuthorityName	ST	O	A human readable name or mnemonic for the assigning authority. The Assigning Authority Name has no computational value. The purpose of an Assigning Authority Name is to assist an unaided human interpreter of an II value to interpret the authority. Note: no automated processing must depend on the assigning authority name to be present in any form.
Displayable	BL	O	Specifies if the identifier is intended for human display and data entry (displayable = true) as opposed to pure machine interoperation (displayable = false).

These actors are not required to provide a value for element assigningAuthorityName. However, if they choose to provide a value of this element and generate both HL7 V2 messages and HL7 V3 messages or CDA documents, the same requirement for the Patient Identifier Cross-reference Manager applies (see Section E.2.1).

E.2.3 Examples of use

The similar case of Metropolitan Medical Center in Section E.1.2 is used to provide HL7 V3 II data type for patient identifier expression in this section. Since element root of the II data type is always required and must be an ISO OID, the example case is adopted (compared to Section E.1.2).

E.2.3.1 Data sent by source systems

The source systems provide data to the Patient Identifier Cross-reference Manager. These data are sent in a Patient Identity Feed HL7 V3 [ITI-44] transaction.

• Patient Smith’s Social Security number is 666-99-4452. This number is assigned by the U.S. Social Security Administration, which uses a known ISO Object Identifier for issuing the Social Security Numbers, 2.16.840.1.113883.4.1.

  As registered in the HL7 OID registry at http://www.hl7.org/oid/index.cfm

• Patient Smith’s medical record number is 9990-99497. This number is assigned by Metropolitan Medical Center. The ISO OID of its medical record number domain is 1.2.xx.yyyyy.123.4567.

  This OID is fictitious, which is emphasized by the incorrect formatting using letters

• Patient Smith’s medical insurance number is 99998410. This number is assigned by MLH Life & Casualty Company, whose ISO OID for issuing insurance numbers is 1.2.xxx.yyyyy.987.6543.

  This OID is fictitious, which is emphasized by the incorrect formatting using letters

The source system will include the patient identifier information of the II data type in a HL7 V3 message generated for the Patient Identity Feed transaction or Patient Identity Cross-Reference or Patient Demographics Query Request as shown in the following:

 

E.2.3.2   Data sent by the Patient Identifier Cross-reference Manager

The Patient Identifier Cross-reference Manager implements HL7 V2 Table 0363, Assigning Authority, which includes the names of identifier domains (assigning authorities) used in the example of Section E.2.3.1:

• US Social Security Administration: USSSA
• Medical record number domain of Metropolitan Medical Center: 99MMC
• Insurance number domain of MLH Life & Casualty Company: 99MLHLIFE

To send the patient identifiers, the Patient Identifier Cross-reference Manager builds a HL7 V3 message as follows: