1. Infrastructure—Patient Index and Demographics Implementation Strategies
Yongjian Bao
GE Healthcare
May 16, 2007

2. Why Patient Identity Management
Establishing Reliable Patient Identity is a Critical Infrastructure Component in Health IT
Bind clinical data to its subject of care
Identity Life-Cycle Management is the Key to Accurate Identification of Patient
Ensure consistent patient data across all clinical domains and applications
EHR Drives Need for Patient Identity Process Cross Health Enterprises
Collect and access to Longitudinal EHR data

3. EHR Drives Needs for Patient Identity Management inter- and intra-Enterprise
US Exam
System
Physician Office
Patient Registration
Patient Registration
Access Info in EHR
Access Info in EHR
ED Application
Community Clinic
Lab Info. System
PACS
Patient Registration
Document Repository
Provide Info to EHR
EHR
PACS
Access Info in EHR
Provide Info
to EHR
Provide Info
to EHR
EHR System
Document Repository
Reliable, Accurate Patient Identity is the Key to Integrate Clinical Applications
Teaching Hospital

4. Patient Identity Problems
Establish Patient Identity
Manage Patient Identity Life-Cycle
Update / add new attributes, link / merge, end of life, etc.
Patient Identification at Point of Care
Find Detailed Demographics Information
Locate Patient Record in Other Institutions
Solution: IHE Patient Identity Integration Profiles

5. Patient Identity Model

6. Patient Identity Model
Patient Identity Record
Identifying traits
Other data items
Patient ID: A Symbol to Uniquely Identify each Record
Patient ID Domain: A Namespace issuing unique Patient ID
Namespace ID
Unique ID / Unique ID Type
Identification: A Process to Bind a Patient ID to a Record
Patient ID Domain
Patient ID
Patient Identifying Traits
Patient identity Record
Patient Identifying Traits
Patient Identifying Traits
Additional Patient Data Items
Additional Patient Data Items
Additional Patient Data Items
Patient Identity Model

7. Patient Identity Source
Patient Identity Source: a Collection of Records Created from a Patient Identity Model
Identified in the Same Domain(s)
Administered under the Same Policy
A Patient Identity Source Decides Its Own Identifier Domain(s) and Administration Policy
Different Organizations Often Have Their Own Patient Registries, and therefore Different Patient Identity Sources
MAIN HOSPITAL
29764
Patient identity Record
James A. Massie
Male
171 Zoberlein, Ishpeming
MI 49849
76363
91432
63537
Patient identity Record I
Asian
CFR
James Addison
Patient identity Record
Alice Smith
Female
123 South Street, New York
NY 10021
Patient identity Record
Mary Jones
Female
1634 J St, Apt. 214, Davis
CA 95616
John Smith
Male
N2378 South St.. Madison
WI 53711 I
African American
AMT
Carl Anderson I
American Indian
AME
Dr. John Griffin I
White
ABC
Ellen Massie
Patient Identity Source

8. Patient Identity in Multiple Sources
AL-6625
29764
US Exam
System
ED Application
Physician Office
62627
PACS
Document Repository
29764
EHR System
Document Repository
PACS
Lab Info. System
Community Clinic
Teaching Hospital

9. EMPI Patient Identification Domain
Enterprise MPI
Enterprise
MPI
US Exam
System
ED Application
Physician Office
PACS
Document Repository
EHR System
Document Repository
PACS
Lab Info. System
Community Clinic
Teaching Hospital
EMPI Patient Identification Domain

10. IHE Patient Administration Management (PAM) Integration Profile

11. Patient Administration Management Integration Profile: Abstract
Patient Identity and Patient Encounter Management for All Clinical Domains
Source – Consumer notification messaging model … both in- and outpatient settings
Identity life-cycle management … creation, update, merge / link
Encounter - movement model … historical events tracking and updating
Designed with HL7 2.5 Standard Conformance Profile Structure
Static Constraints on message, segment, and data type levels
Dynamic Constraints on event level
Message control and acknowledgement definition … robust error reporting by leveraging HL7 2.5
Option Packages
Support a wide range of application needs
Patient Encounter Source
ITI-31: Patient Encounter Management
Patient Encounter Consumer
Patient Demographics Source
ITI-30: Patient Identity Feed
Patient Demographics Consumer

12. Patient Administration Management Integration Profile: Encounter Movement Model
time
Location GG & attending doctor X
Emergency & attending doctor U
Location BB & attending doctor X
A04
A06
A02
A03
Patient received at Emergency room by attending doctor U. (A04 / patient class E).
Doctor U admits the patient (A06 / patient class = I), into location BB, referring him to attending Doctor X
The patient is moved to location GG (A02Transfer), keeping X for attending doctor.
The patient is healed and leaves the hospital (A03: Discharge).
Segment ZBE is used in any INSERT event to attach an ID to the movement but does not change the original semantics of the event: ZBE-4 = INSERT.
Segment ZBE can be in any CANCEL event, but does not change the original semantics of the event: ZBE-4 = CANCEL.
Segment ZBE is used in Z99 trigger to update a current or historical movement: ZBE-4 = UPDATE
Movement ID R
Start Movement Date/Time
End Movement Date/Time O
Movement Action Code
Historical Movement Indicator
Original Event Code C
Responsible Ward Code
ZBE Segment Definition
In some acute care settings, both the billing process and care provision process require precise knowledge of the movements of the inpatient during his or her stay in the hospital. Applications acting as Patient Encounter Supplier or Patient Encounter Consumer, divide the period of the encounter into “sub-encounters” delimited by the Movements. Each of these “sub-encounters” provides a specific context to record and invoice the acts produced within this period. However, if applications on both ends manage sub-encounters, which are periods of time, the messages of transaction ITI-31 communicate Movements as events. Hence, applications manage periods of time, but the messages carry the discrete events that delimit these periods of time.
Illustration:
1. Patient received at Emergency room by attending doctor U. (A04 / patient class E).
2. Doctor U admits the patient (A06 / patient class = I), into location BB, referring him to attending Doctor X .
3. The patient is moved to location GG (A02Transfer), keeping X for attending doctor.
4. The patient is healed and leaves the hospital (A03: Discharge).
These 4 real world events are expressed with 5 trigger events / messages, two of which occur at the same time (step 2). Here the encounter will be divided into 3 sub-encounters:

13. Patient Administration Management Integration Profile : Actors
Patient Demographics Source
Responsible for administering patient identity and maintaining its record (incl. demographics, e.g., name, address, and related persons), and supplying the patient data and their updates to Patient Demographics Consumer
Patient Demographics Consumer
Uses demographic information provided by the Patient Demographics Source about a patient
Patient Encounter Source
Responsible for maintaining encounter information about a patient, and supplying the encounter data and their updates to the Patient Encounter Consumer
Must be grouped with either Patient Demographics Source or Patient Demographics Consumer
Patient Encounter Consumer
Uses patient encounter information provided by Patient Encounter Source

14. Patient Identifying Traits in PID Segment
Patient Administration Management: Patient Identity Feed Transaction (ITI-30)
Actor Requirements
Patient demographics source – Required
Patient demographics consumer – Required
Patient Identity Management
Patient Identifying Traits
Messages to notify patient identity life-cycle events:
Creation / Update / Duplicates Resolution
Base Set of Messages + 2 Options
Patient identifying traits defined in base messages
Two ways to handle patient identity duplicates
At least one of them must be supported … it can be defined in national extensions
Patient Identifying Traits in PID Segment
PID-3
Patient Identifier List R
PID-5
Patient Name R
PID-7
Date / Time of Birth CE
PID-8
Administrative Sex CE
PID-11
Patient Address CE
PID-31
Identifier Unknown Indicator CE
PID-32
Identifier Reliability Code CE
PID-35
Species Code CE
PID-36
Breed Code CE
Merge Two Patients (A40/A39)
Link Patient Information (A24/A24)
Unlink Patient Information (A37/A37)
Create New Patient (A28/A05)
Update Patient Information (A31/A05)
Change Patient Identifier List (A47/A30)

15. Patient Administration Management: Patient Encounter Management Transaction (ITI-31)
Actor Requirements
Patient encounter source – Required
Patient encounter consumer – Required
Patient Encounter Management
Encounter level events
Movement level events
Movement identification w/ ZBE segment
Update of current and historic event w/ Z99 trigger
All events: insert / cancel (if applicable)
Base Set of Messages + 5 Options
Only base set is required for basic encounter management
Both the source and consumer actors can choose any (logically reasonable) combination of options to support their functional needs
Historic movement option extends all events in base and optional messages
Temporary Patient Transfers Tracking
Patient departing – tracking (A09/A33)
Patient arriving – tracking (A10/A32)
Advanced Encounter Management
Change attending doctor (A54/A55)
Leave of absence (A21/A52)
Return from leave of absence (A22/A53)
Move account information (A44)
Pending Event Management
Pending admit (A14/A27)
Pending transfer (A15/A26)
Pending discharge (A16/A25)
Extend all events in base and optional messages to manage historic movement events by adding ZBE segment
Historic Movement Management
In-/Outpatient Encounter Management
Pre-admit patient (A05/A38)
Change outpatient to inpatient (A06)
Change inpatient to outpatient (A07)
Transfer patient (A02/A12)
Basic Encounter Management
Admit inpatient (A01/A11)
Register outpatient (A04/A11)
Discharge patient (A03/A13)
Update patient information (A08)
Merge Patient Identifier List (A40)

16. IHE Patient Identifier Cross-Referencing (PIX) Integration Profile

17. Patient Identifier Cross-Referencing Integration Profile: Abstract
Cross-Mapping of Patient Identity Records of the Same Patient from Different Domains
Specify identifying traits, but leave matching design open for implementation
Specify consumer behaviors on receiving PIX query responses
PIX Domain … the Scope Supported in PIX Manager
Not a real id domain, but a set of cross-mapped id domains
PIX Manager provides only ID-cross-mapping services … no identity details
HL7 Messages to Access PIX Services
PIX Query: Look-up identifiers in other domains
PIX Update Notification: Subscription service to receive cross-mapped identifiers and their changes
HL7 2.5 version supported since 2003 … HL7 V3 support in trial implementation phase
ITI-8: Patient Identity Feed
Patient Identity Source
Patient Identifier Cross-Referencing Consumer
ITI-9: PIX Query
ITI-10: PIX Update Notification
Patient Identifier Cross-Referencing
Manager
ITI-9
ITI-10

18. Patient Identifier Cross-Referencing Integration Profile : Actors
Patient Identity Source
Responsible for administering patient identity and maintaining its record (incl. demographics, e.g., name, address, and related persons), and feeding the patient identity data and their updates to Patient Identifier Cross-Referencing Manager
Patient Identifier Cross-Referencing Consumer
Queries Patient Identifier Cross-Referencing Manager for patient’s identifiers in other domains
Optionally, subscribes PIX update notification service to receive all changed (new) x-ref relationship of patient identifiers from different domains.
Patient Identifier Cross-Referencing Manager
Responsible for receiving patient identify feeds from different sources (domains), using them to create / update x-ref relationship of the identity records for the same patient, and maintaining its x-ref relationship repository
Serves PIX query request by looking up x-ref identifiers in its repository
Serves PIX update notification by sending messages to all subscribers when any change occurred in x-ref relationship of the patient identifiers from the domains of their interest

19. Patient Identifying Traits
Patient Identifier Cross-Referencing : Patient Identity Feed Transaction (ITI-8)
Implementation Considerations:
Send Patient Identifier in PID-3, always with Patient Identifier Domain information (PID-3.4)
If the Identity Source supports multiple Patient Identifiers, list all of them in PID-3
Use ISO OID to identify Patient Identifier Domain if possible … if the identity feed is to Document Registry, this is required.
Send detailed demographics … all of the traits IHE required for PIX Manager and more
Actor Requirements
Patient identity source – Required
Patient identifier cross-referencing manager – Required
Feed Patient Identity records from different sources to PIX Manager for cross-referencing
HL7 Standard: Version and Higher
HL7 V3 Support of
ITI-8 Trial Implementation
Supplement Since 2006
PID-3
Patient Identifier List R
PID-5
Patient Name
PID-7
Date / Time of Birth R+
PID-8
Administrative Sex
PID-11
Patient Address R2
PID-13
Phone Number - Home
PID-14
Phone Number - Work
PID-16
SSN Number - Patient
PID-25
Driver’s License Number
Patient Identifying Traits
PID-6
Mother’s Maiden Name
PIX Manager
Document Registry
Patient Identity Source
Patient Identity Source
PIX Manager
ADT^A01
ADT^A04
ADT^A05
ADT^A08
ADT^A40
Run Patient ID X-Ref Process
Trigger PIX Notification if Any Change in Patient ID X-Ref Relationship within PIX Manager
ACK^Axx

20. Patient Identifier Cross-Referencing : PIX Query Transaction (ITI-9)
Actor Requirements
Patient identifier Cross-referencing consumer – Required
Patient identifier cross-referencing manager – Required
Look-up Patient Identifier from one domain to other domains
Query Name: QPD-1=“IHE PIX Query”
HL7 Immediate Query Mode is Required
HL7 Standard: Version 2.5
Implementation Considerations:
Specify one patient identifier with domain information (QPD-3) as search key, to look up identifiers of the same patient in other domains – “Domains Returned”
Specify Domains Returned in QPD-4
Use ISO OID to specify all patient identifier domain if possible
If Domains Returned are not specified, the PIX Manager returns patient identifiers in all domains it knows, which are cross-linked to the identifier in PIX query request.
PIX query response may include multiple identifiers in one domain … you SHALL use or ignore them all
HL7 V3 Support of
ITI-9 Trial Implementation
Supplement Since 2006
Patient Identifier Cross-Referencing Consumer
Patient Identifier Cross-Referencing Manager
QBP^Q23
MSH|^~\&|CLINREG|WESTCLIN|HOSPMPI|HOSP| ||QBP^Q23^QBP_Q21|8699|P|2.5
QPD|Q23^Get Corresponding IDs^HL70471|111069|112234^^^METRO HOSPITAL|^^^WEST CLINIC~^^^SOUTH LAB
RCP||I|
Process PIX Query Request
MSH|^~\&|HOSPMPI|HOSP|CLINREG|WESTCLIN| ||RSP^K23^RSP_K23|1|P|2.5|
MSA|AA|8699|
QAK|111069|OK|Q23^Get Corresponding IDs^HL70471|1|
QPD|Q23^Get Corresponding IDs^HL70471|111069|112234^^^METRO HOSPITAL|^^^WEST CLINIC~^^^SOUTH LAB|
PID|||56321A^^^WEST CLINIC~66532^^^SOUTH LAB||~^^^^^^S|
RSP^K23

21. Patient Identifier Cross-Referencing : PIX Update Notification Transaction (ITI-10)
Implementation Considerations:
Notification transaction is initiated from the PIX Manager to PIX Consumer
Provide a method for PIX Consumer to subscribe the notification
Domain(s) of interest
Network address to send the notification
The PIX notification service is useful for a PIX Consumer which maintains a local cache of patient identifier cross-referencing relationship to avoid frequent PIX queries.
Notification may include multiple identifiers in one domain … you SHALLL use or ignore them all
Actor Requirements
Patient identifier cross-referencing consumer – Optional
Patient identifier cross-referencing manager – Required
Enable PIX Consumer locally cache (a portion of) x-ref’ed identifiers, mirrored from the PIX Manager
HL7 Standard: Version 2.5
HL7 V3 Support of
ITI-10 Trial Implementation
Supplement Since 2006
Patient Identifier Cross-Referencing Consumer
Patient Identifier Cross-Referencing Manager
Any Process Resulting in Change in Patient ID X-Ref Relationship
ADT^A31
MSH|^~\&|HOSPMPI|HOSP|CLINREG|WESTCLIN| ||ADT^A31^ADT_A05|8703|P|2.5|
EVN|A31| ||||
PID|||56321A^^^WEST CLINIC~66532^^^SOUTH LAB||~^^^^^^S|
ACK^A31

22. PIX Process Flow: Overview
PIX Domain
Patient ID Domain A
Patient Registration
US Exam
System
14355
Patient ID Domain B
L-716
Patient ID Feed
PIX Manager
A87631
Patient ID Feed
Patient ID X-Ref Query
35424
14355
Patient ID X-Ref Query
Patient Registration
L-716
Clinical Information System
Patient ID Feed
Patient ID Feed
Patient ID X-Ref Notification
Patient ID X-Ref Notification
Patient Registration
EHR System
35424
Patient ID Domain C
Patient ID Domain D
A87631
Patient Registration
PACS

23. PIX Process Flow: Query and Notification Examples
PIX Domain
Patient ID Domain A
Patient Registration
US Exam
System
14355
S1763
14355
98532
Y-456
L-716
D-776
DF-45
A74630
A87631
35424
63452
23511
Patient ID Domain B
L-716
PIX Manager
A87631
A: S1763
B: ?
D: ?
35424
14355
Patient Registration
L-716
A: S1763
B: Y-456
D: A74630
Clinical Information System
PIX Query
Patient Registration
EHR System
35424
Patient ID Domain C
Patient ID Domain D
A87631
A: 98532
B: DF-45
C: 23511
Patient Registration
PIX Notification
PACS

24. PIX and MPI: Combined Use in Typical IHE View
PIX Domain
Patient ID Domain A
Patient Registration
US Exam
System
14355
Patient Registration
Clinical Information System
L-716
Patient ID Domain B
Patient ID Feed
PIX Manager M
35424
A87631
14355
L-716
Patient ID Feed
A87631
35424
Patient ID Feed
Patient ID Feed
Patient ID Feed
Patient Registration
EHR System
35424
Patient ID Domain C
Patient ID Domain D
A87631
Patient Registration
Master Patient
Index (MPI) M
Patient ID Domain MPI
PACS

25. PIX and MPI: MPI Joins in PIX as One Domain
PIX Domain
Patient ID Domain A
Patient Registration
US Exam
System
14355
Patient ID Domain B
L-716
Patient ID Feed
PIX Manager M
35424
A87631
14355
L-716
A87631
Patient ID Feed
35424
14355
Patient Registration
L-716
Clinical Information System
Patient ID Feed
Patient ID Feed
Patient ID Feed
Patient Registration
EHR System
35424
Patient ID Domain C
Patient ID Domain D
A87631
Patient Registration
Master Patient
Index (MPI) M
Patient ID Domain MPI
PACS

26. IHE Patient Demographics Query (PDQ) Integration Profile

27. Patient Demographics Query Integration Profile: Abstract
PDQ Information Model
Query by parameter – patient identifying traits
Multiple patient information sources
Patient identifiers from other domains
Patient Identification at Point of Care
Partial identifying traits  patient pick list
Patient visit traits  patient pick list
Patient identifier  patient record details
Acquire Patient Identifier in a Different Domain … an Alternative Way to PIX
Typically used in XDS environment to acquire patient identifier in Affinity Domain
Standardized HL7 QBP Message Profile
Query response continuation protocol
HL7 2.5 version Supported since 2003 … HL7 V3 support in trial implementation phase
Patient Demographics Consumer
ITI-21: Patient Demographics Query
Patient Demographics Supplier
ITI-22: Patient Demographics and Visit Query

28. Patient Demographics Query Integration Profile: Actors
Patient Demographics Supplier
Capable of supplying patient identity information from one or more patient identity sources, and using these data to serve query requests from patient demographics consumer by returning identifiers and demographic information for all patient records matching the search criteria specified in a request.
Note that patient demographics supplier does not need to be a patient identity source itself, but can be an actor which can authoritatively provide the same information maintained in a patient identity source. In fact, it can provide the patient demographics information from multiple patient identity sources.
Patient Demographics Consumer
Requests demographics data of patient(s) matched to a set of search criteria (e.g., patient identifier or partial name) from Patient Demographics Supplier, and uses the returned patient demographics data for its application purposes
Patient Demographics Consumer can specify the search criteria in various ways, from a patient identifier in the identification domain used by the patient identity source to exactly locate the target patient record, to an incomplete set of demographics items (e.g., patient’s last name and administrative sex) to request a list of patients for selection.

29. Patient Demographics Query Use Cases
Patient Identity Source
ICU nurse queries patient ID and name using the current bed number as search key
Physician at office queries a list of patient records with partial patient info as search keys
Lab tech queries patient info, and asks the Patient ID in another domain.
ICU Bed-site System
Physician Office System
Lab Information System

30. PDQ Model: Patient Information Source and Patient Information Supplier
Patient Demographics Supplier
Patient Demographics Supplier
Patient Identity Source A
14355
J-718
RAD-0202
Patient Identity Source B
A PDQ request is always defined in one Source, where patient records are identified in the source’s patient identifier domain.
The Supplier may know patient identifiers from Other Domains corresponding to its patient records.
The Supplier may support multiple Sources – the Consumer must select which source a query to be served.

31. Specify Patient Identity Source in PDQ Request
Patient Demographics Supplier
Patient Identity Source A
14355
J-718
Patient Identity Source B
14355
14355
Example given in HL7 2.5 …
HL7 V3 since 2008
PDQ Request: QBP^Q22 or QBP^ZV1
MSH-5 to select Patient Identity Source
QPD-8 to specify Other Domains from which additional Patient ID are to be returned (optional), e.g., Patient ID in XDS Affinity Domain
Patient Demographics Consumer
Physician Office System

32. Patient Identifying Traits
Patient Demonstration Query: Patient Demographics Query Transaction (ITI-21)
Actor Requirements
Patient demographics supplier – Required
Patient demographics consumer – Required
Query Name: QPD-1=“IHE PDQ Query”
HL7 Query Immediate Mode Required
HL7 Query Continuation Protocol Supported
HL7 Standard: Version 2.5
Implementation Considerations:
Specify search keys in QPI-3 – Patient ID or demographics traits as PID/PD1 fields. They are AND’ed
List of Sources supported by the Suplier … Specifying a unknown Source in MSH-5 causes error condition
List of Other Domains supported in each Source … Specifying a unknown domain causes error condition
Requested Patient ID in Other Domains may not be returned in PDQ response. It is not error condition.
Return detailed demographics … those required and more
IHE neither specifies nor prohibits: additional identifying traits for matching, wildcards matching, repetitions in one PID field
HL7 V3 Support of
ITI-2 since 2008
PID-3
Patient Identifier List R
PID-5
Patient Name
PID-7
Date / Time of Birth R2
PID-8
Administrative Sex
PID-11
Patient Address
PID-18
Patient Account Number
Patient Identifying Traits
Patient Demographics Consumer
Patient Demographics Supplier
Use MSH-5 to designate Patient Information Source to search
If Patient ID in other domains needed, specify those domains in QPD-8 (only include domains the supplier supports!)
Use RCP-3 for incremental responses if desired
Copy incoming MSH-5 to MSH-3 in response to indicate the source of patient info.
Add requested Patient ID in PID-3 with fully specified domains
Return Continuation Pointer if incremental response is in action and there are more results to return
QBP^Q22
Process PDQ Query Request
RSP^K22

33. Patient Identifying Visit Traits
Patient Demonstration Query: Patient Demographics and Visit Query Transaction (ITI-22)
Implementation Considerations:
Specify search keys in QPI-3 – Patient ID or demographics traits as PID/PD1/PV1/PV2 fields. They are AND’ed
No keys of visit information required for Supplier, but some of the keys recommended. Supplier’s support of these visit key depends on care settings. Consumer needs to know what keys a Supplier supports
Return detailed demographics … those required and more
All query keys and features in PDQ query supported … as well issues remain
Actor Requirements
Patient demographics supplier – Optional
Patient demographics consumer – Optional
Query Name: QPD-1=“IHE PDVQ Query” HL7 Query Immediate Mode Required
HL7 Query Continuation Protocol Supported
HL7 Standard: Version 2.5
HL7 V3 Support of
ITI-22 since 2008
PV1-1
Patient Class R
PV1-3
Assigned Patient Location R2
PV1-7
Attending Doctor
PV1-8
Referring Doctor
PV1-9
Consulting Doctor
PV1-10
Hospital Service
Patient Identifying Visit Traits
PV1-17
Admitting Doctor
PV1-19
Visit Number
Patient Demographics Consumer
Patient Demographics Supplier
QBP^ZV1
RSP^ZV2
Process Demographics and Visit Query Request
Use MSH-5 to designate Patient Information Source to search
If Patient ID in other domains needed, specify those domains in QPD-8 (only include domains the supplier supports!)
Use RCP-3 for incremental responses if desired
Copy incoming MSH-5 to MSH-3 in response to indicate the source of patient info.
Add requested Patient ID in PID-3 with fully specified domains
Return Continuation Pointer if incremental response is in action and there are more results to return

34. PDQ: Incremental Query Response Support
Patient Demographics Consumer
Patient Demographics Supplier
Implementation Considerations:
Throughout all interactions in a continuation process, Query Tag (QAK-1) is used to correlate all request/response messages associated with the same query
Supplier should declare its time-out policy to terminate a query continuation
In continuation, consumer resends the original query request in a new message – new value in MSH-10
QBP^Q22 or QBP^ZV1
RCP-1=“I” – R
RCP-2=n - O
RSP^K22 or RSP^ZV2
DSC-1= CP
If continuation requested and supplier has more record to return
Loop
[If RSP contains a valid CP]
Loop
[If RSP contains a valid CP, and Consumer wants to receive the next block of results]
QBP^Q22 or QBP^ZV1
Send original query request in a new message w/ DSC echoing CP received in RSP
Fetch next continuation block of matched results
Use MSH-5 to designate Patient Information Source to search
If Patient ID in other domains needed, specify those domains in QPD-8 (only include domains the supplier supports!)
Use RCP-3 for incremental responses if desired
Copy incoming MSH-5 to MSH-3 in response to indicate the source of patient info.
Add requested Patient ID in PID-3 with fully specified domains
Return Continuation Pointer if incremental response is in action and there are more results to return
RSP^K22 or RSP^ZV2
DSC-1= CP
If supplier has more record to return. The CP is a new one
Example given in HL7 2.5 …
HL7 V3 supported since 2008
[else]
QCN^J01
ACK^QCN

35. PDQ Message Example - Request
MSH|^~\&|CLINREG|WESTCLIN|HOSPMPI|HOSP| ||QBP^Q22^QBP_Q21|8799|P|2.5
QPD|Q22^Find Candidates^HL70471|111069| HOSPITAL~^^^SOUTH LAB
RCP|I|20^RD

36. PDQ Message Example: Response
MSH|^~\&|HOSPMPI|HOSP|CLINREG|WESTCLIN| ||RSP^K22^RSP_K21|134410|P|2.5
MSA|AA|8799
QAK|111069|OK|Q22^Find Candidates^HL70471|3
QPD|Q22^Find HOSPITAL~^^^SOUTH LAB|
PID|||66785^^^METRO HOSPITAL~66532^^^SOUTH LAB||Smith^John|| |M||C|N2378 South Street^^Madison^WI^53711|
QRI|95||MATCHWARE 1.2|
PID|||87443^^^METRO HOSPITAL~651189^^^SOUTH LAB||Smith^Jon|| |M||C|124 Second Street^^Madison^WI^53711|
QRI|90||MATCHWARE 1.2|
PID|||43266^^^METRO HOSPITAL~81209^^^SOUTH LAB||Smithy^John|| |M||C|W11234 Bay Drive^^Lodi^WI^53555|
QRI|85||MATCHWARE 1.2|

37. Patient Identity Solutions and Implementation Strategy

38. Patient Identifying Traits Required in IHE Integration Profiles
PID-3
Patient Identifier List R
PID-5
Patient Name
PID-7
Date / Time of Birth CE
PID-8
Administrative Sex
PID-11
Patient Address
PID-31
Identifier Unknown Indicator
PID-32
Identifier Reliability Code
PID-35
Species Code
PID-36
Breed Code
Patient Identifying Traits in PID Segment
PAM
PID-3
Patient Identifier List R
PID-5
Patient Name
PID-7
Date / Time of Birth R+
PID-8
Administrative Sex
PID-11
Patient Address R2
PID-13
Phone Number - Home
PID-14
Phone Number - Work
PID-16
SSN Number - Patient
PID-25
Driver’s License Number
Patient Identifying Traits
PID-6
Mother’s Maiden Name
PIX
PID-3
Patient Identifier List R
PID-5
Patient Name
PID-7
Date / Time of Birth R2
PID-8
Administrative Sex
PID-11
Patient Address
PID-18
Patient Account Number
Patient Identifying Traits
PDQ

39. Patient Identity Profiles Implementation: Security Considerations
ITI-8
ITI-21
ITI-22
Patient Demographics Consumer
ITI-30
Patient Encounter Source
ITI-31
Patient Encounter Consumer
ITI-9
ITI-10
Patient Identifier Cross-Referencing Consumer
Patient Demographics Supplier
Patient Identifier Cross-Referencing
Manager
Patient Identity Source
Patient Demographics Source
Patient Record
Patient Record
Patient Record
Query Event
Query Event
Patient Record
ATNA

40. Patient Identity Profiles Implementation: System Deployment Considerations
Patient Encounter Consumer
Patient Encounter Source
ITI-31
Patient Record
Patient Demographics Consumer
Patient Record
Patient Demographics Source
ITI-30
Patient Demographics Supplier
Patient Identifier Cross-Referencing
Manager
ITI-8
Patient Identity Source
Patient Record
Query Event
Query Event
Patient Record
ITI-21
ITI-22
ITI-9
ITI-10
Patient Demographics Consumer
Patient Identifier Cross-Referencing Consumer
ATNA

41. Registries Data & Services Ancillary Data & Services
Implementation Example: Using PIX to Cross-Link Patient Identities across Different Organizations
Longitudinal Record Services
Common Services
Communication Bus
CANADA INFOWAY JURISDICTIONAL INFOSTRUCTURE
Registries Data & Services
Ancillary Data & Services
EHR Data & Services
Data Warehouse
EHR IP
HIAL
EHR IP Standards
Client Registry
Outbreak Mgmt
PHS Reporting
Shared Health
Record
Drug Information
Diagnostic Imaging
Laboratory
Health Information
Provider Registry
Location Registry
Business Rules
EHR Index
Message Structures
Normalization Rules
Terminology Registry
Security Mgmt
Privacy Data
Configuration
HIAL
EHR SCP Standards
PIX
XDS/i
Centricity PACS
IHE PIX for Client Registry
IHE XDS /I for Information Exchange
XDS Consumer
XDS Source (local repository)

42. Clinical Doc Locations Aggregated Lab Results (Local and Remote)
Implementation Example: Using PDQ to Query Patient Identities Information
CDX Gateway
ISB
ISB
ISB
ISB
RLS
RLS
Boston MC
CDX Gateway
CHC Repositories
BMC XDS Domain
Document
Registry
Cross-Domain Bridge
BMC Physician Retrieves Lab Results
Centricity sends query to BMC CDX Gateway, which passes it to the MA-SHARE Gateway/ISB & queries RLS for location of local patient records
MA-SHARE Gateway retrieves clinical doc locations (metadata) from XDS registry
ISB Queries other RHIOs (Indiana Health Information Exchange
Aggregated query metadata displayed on EMR
Physician selects documents to view
Whittier HC
South
Boston HC
GE Centricity
Clinical Doc Locations
Aggregated Lab Results (Local and Remote)
Query
Courtesy of

43. IHE Patient Identity Profiles Summary
Communication Mechanism: HL7 2.x Messages
Some of these profiles are being adapted to HL7 V3 messages using Web Services (work in progress)
Standardized Patient Identifying Traits
Standardized Messages for Patient Records Life-Cycle Management Events
Standardized Query Messages to Acquire Patient Identity / Demographics Information
Defined Cross-Referencing Mechanism to Map Identities across Different Domains

44. Further IHE Documents IHE Web site: Technical Frameworks:
Technical Frameworks:
ITI V3.0
Technical Framework Supplements - Trial Implementation
July 2005: PAM Integration Profile (Revised Nov. 2006)
Non-Technical Brochures :
Calls for Participation
IHE Fact Sheet and FAQ
IHE Integration Profiles: Guidelines for Buyers
IHE Connect-a-thon Results
Vendor Products Integration Statements

45. Cross-Enterprise Information Sharing
XAD Patient
Identity Source M
US Exam
System
14355
Physician Office
A87631
Provide & Register
Register
Retrieve Document
Query Document
Patient Identity Feed
Query Document
Retrieve Document
Provide & Register
Register
ED Application
Community Clinic
Lab Info. System
PACS
L-716
Document Registry
PACS
Document Repository
EHR System
Document Repository
Query Document
Register
Provide & Register
Retrieve Document
Teaching Hospital
XDS Clinical Affinity Domain

46. Questions?