23 Patient Identifier Cross-referencing HL7 V3 (PIXV3)

The Patient Identifier Cross-referencing HL7 V3 Integration Profile (PIXV3) is targeted at cross-enterprise Patient Identifier Cross-reference Domains (as defined in Section 5) as well as healthcare enterprises with developed IT infrastructure. The discussion in Section 5 fully applies here, with the obvious adjustments to the referenced transactions.

23.1 PIXv3 Actors/Transactions

The actors in this profile are the same as the actors defined in the PIX Profile (Section 5.1). Figure 23.1-1 shows the actors directly involved in the Patient Identifier Cross-referencing HL7 V3 Integration Profile and the relevant transactions between them. Other actors that may be indirectly involved due to their participation in other related profiles are not shown.

Table 23.1-1 lists the transactions for each actor directly involved in the Patient Identifier Cross-referencing Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed in the Section 23.2.

Table 23.1-1: Patient Identifier Cross-referencing HL7 V3 Integration Profile - Actors and Transactions

Actors	Transactions	Optionality	Section
Patient Identity Source	Patient Identity Feed HL7 V3 [ITI-44]	R	ITI TF-2: 3.44
Patient Identifier Cross-reference Consumer	PIXV3 Query [ITI-45]	R	ITI TF-2: 3.45
	PIXV3 Update Notification [ITI-46]	O	ITI TF-2: 3.46
Patient Identifier Cross-reference Manager	Patient Identity Feed HL7 V3 [ITI-44]	R	ITI TF-2: 3.44
	PIXV3 Query [ITI-45]	R	ITI TF-2: 3.45
	PIXV3 Update Notification [ITI-46]	R	ITI TF-2: 3.46

The transactions in this profile directly correspond to the transactions used in the PIX Profile (Section 5) and provide the identical functionality. Table 23.1-2 describes this correspondence.

Table 23.1-2: Transactions Correspondence between the PIX and PIXV3 Profiles

Transactions in PIX	Vol. & Section	Transactions in PIXV3	Section
Patient Identity Feed [ITI-8]	ITI TF-2: 3.8	Patient Identity Feed HL7 V3 [ITI-44]	ITI TF-2: 3.44
PIX Query [ITI-9]	ITI TF-2: 3.9	PIXV3 Query [ITI-45]	ITI TF-2: 3.45
PIX Update Notification [ITI-10]	ITI TF-2: 3.10	PIXV3 Update Notification [ITI-46]	ITI TF-2: 3.46

23.1.1 PIXV3 Required Actor Groupings

An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2).

Table 23.1.1-1: PIXV3 - Required Actor Groupings

PIXV3 Actor	Actor(s) to be grouped with	Reference
Patient Identity Source	CT / Consistent Time	ITI TF-1: 7.1
Patient Identifier Cross-reference Consumer	CT / Consistent Time	ITI TF-1: 7.1
Patient Identifier Cross-reference Manager	CT / Consistent Time	ITI TF-1: 7.1

 

Section 23.6 describes some optional groupings that may be of interest for security considerations.

23.2 PIX V3 Actor Options

Options that may be selected for this Integration Profile are listed in the Table 23.2-1 along with the actors to which they apply. Dependencies between options when applicable are specified in notes.

Table 23.2-1: Patient Identifier Cross-referencing HL7 V3 - Actors and Options

Actor	Options	Vol. & Section
Patient Identity Source	Pediatric Demographics	ITI TF-1: 23.2.1
Patient Identifier Cross-reference Manager	Pediatric Demographics	ITI TF-1: 23.2.1
Patient Identifier Cross-reference Consumer	PIXV3 Update Notification	ITI TF-2: 3.46

23.2.1Pediatric Demographics Option

The experience of immunization registries and other public health population databases has shown that matching and linking patient records from different sources for the same individual person in environments with large proportions of pediatric records requires additional demographic data.

In particular, distinguishing records for children who are twins, triplets, etc. – that is, avoiding false positive matches - may be difficult because much of the demographic data for the two individuals matches. For instance, twin children may have identical last names, parents, addresses, and dates of birth; their first names may be very similar, possibly differing by only one letter. It can be very difficult for a computer or even a human being to determine in this situation whether the slight first name difference points to two distinct individuals or just a typographical error in one of the records. Additional information is extremely helpful in making this determination.

Pediatric Demographics makes use of the following six additional demographic fields to aid record matching in databases with many pediatric records.

Field	Reason for inclusion	Value
Mother’s Maiden Name	Any information about the mother is helpful in making a match	Helps create true positive matches
Patient Home Telephone	A telecom helps match into the right household	Helps create true positive matches
Patient Multiple Birth Indicator	Indicates this person is a multiple – twin, triplet, etc.	Helps avoid false positive matches of multiples
Patient Birth Order	Distinguishes among those multiples.	Helps avoid false positive matches of multiples
Last Update Date/Time, Last Update Facility	These fields, although not strictly demographic, can effectively substitute when multiple birth indicator and birth order are not collected. They indirectly provide visit information. Provider visits on the same day may likely indicate two children brought to a doctor together.	Helps avoid false positive matches of multiples

Patient Demographics Consumer Actor s which support the Pediatrics Demographics Option will be able to provide Pediatric Demographics query parameter fields in the Patient Demographics Query transaction [ITI-47], and shall be able to receive and process any values returned for the fields identified as Pediatric Demographics.

Pediatric Demographics query parameter fields are:

• Mother’s Maiden Name
• Patient Home Telephone

Pediatric Demographics are defined as all of the following:

• Mother’s Maiden Name
• Patient Home Telephone
• Patient Multiple Birth Indicator
• Patient Birth Order

23.3 Patient Identifier Cross-referencing HL7 V3 Integration Profile Process Flows

Sections 5.3.1 and 5.3.2 describe use cases that this profile addresses. Figures 5.3-1 and 5.3-2 also apply with the changes to the corresponding PIXV3 transactions as specified in Table 23.1-2.

23.4 Relationship between the PIXV3 Integration Profile and eMPI

The discussion in Section 5.4 fully applies to this profile.

23.5 Patient Identifier Communication Requirement

The patient identifier in HL7 V3 messages is represented by the II data type. This data type has two components: a root, and an extension. For compatibility with the use of patient identifiers in profiles using HL7 V2 messages, and with the specification of the patient identifier in the XDS Profile, the patient identifier SHALL be represented as a root and an extension, where the root is an appropriately assigned OID. The direct correspondence between the II data type and the HL7 Version 2.5 CX data type (used in field PID-3) is shown in ITI TF-2: Appendix R .

23.6 Security Considerations

The implementer of this profile is advised that many risks cannot be mitigated by the IHE profile and instead the responsibility for mitigation is transferred to the vendor, and occasionally to the operational environment.

In order to address identified security risks:

• All actors in PIXV3 should be grouped with a Consistent Time (CT) Profile - Time Client. This grouping will assure that all systems have a consistent time clock to assure a consistent timestamp for audit logging.
• All actors in PIXV3 should be grouped with an Audit Trail and Node Authentication (ATNA) Profile - Secure Node or ATNA Secure Application Actor. This grouping will assure that only highly trusted systems can communicate and that all changes are recorded in the audit log.
• All actors in PIXV3 should be grouped with a Cross-Enterprise User Assertion (XUA) X-Service User or X-Service Provider as appropriate. This grouping will enable service side access control and more detailed audit logging.
• All actors in PIXV3 should be grouped with the appropriate actor from the Enterprise User Authentication (EUA) Profile to enable single sign-on inside an enterprise by facilitating one name per user for participating devices and software.