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.
Figure 23-1: Process Flow with Patient Identifier Cross-referencing HL7 V3
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.
Figure 23.1-1: Patient Identifier Cross-referencing HL7 V3 Actor Diagram
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
|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.