Patient Identity Management

1. Patient Identity Management Eric Heflin Dir of Standards and Interoperability/Medicity

2. Audience/Scope • Agenda • Introduction • Terms Used • The Patient ID Problem • The IHE Solution • For More Information

3. Audience/Scope • Audience • Senior healthcare IT technical executives • Architects • Implementers seeking a broad overview • Scope • Broad context and guidance about the use of IHE standard profiles for patient identifier management across organizational boundaries • Purpose • Provide reusable educational content

4. Terms Used • Patient Identifier: A value controlled and assigned by a single assigning authority (hospital, group of related practices, national health authority, etc.). Note that the same patient can have multiple identifier inside a single domain. • Assigning authority: <need good def> A system (manual or automated) that creates identifiers for objects (patients, transactions, etc.) that are normally unique within a specified domain. • XDS Affinity Domain: <new> An XDS Affinity Domain is a group of healthcare enterprises that have agreed to share health information together using a common set of policies and share a common infrastructure. • Others?

5. IHE Patient identity management Introduction

6. Introduction • IHE has created six standards (profiles) for patient identifier management • Some profiles target patients inside an enterprise • Other profiles target patients across enterprises • This presentation introduces and compares these five of these six profiles (XCPD is covered elsewhere) • <why did we group these together, perhaps have a diagram showing the interplay between the profiles>

7. What Problem is Being Solved? • Problem statement: • How can we correctly identify and manage patient identity across organizational boundaries (with different identifiers in different systems) to accommodate the exchange of health information using a standards-based approach with a high degree of assurance that the information is about the correct patient?

8. IHE Approach IHE has created six mechanisms, or “profiles”, designed to solve different aspects this problem • PIX – Patient Identifier Cross-Referencing • PIXv3 – Patient Identifier Cross-Referencing HL7 V3 • PDQ – Patient Demographics Query • PDQv3 – Patient Demographics Query HL7 V3 • *XCPD – Cross-Community Patient Discovery • PAM – Patient Administration Management *XCPD is discussed in another IHE presentation

9. Patient identity cross-referencing PIX

10. PIX Introduction • The PIX profile supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains. These cross-referenced patient identifiers can then be used by “identity consumer” systems to correlate information about a single patient from sources that “know” the patient by different identifiers. This allows a clinician to have more complete view of the patient information. • This integration profile does not define any specific enterprise policies or cross-referencing algorithms

11. PIX Introduction The Patient Identifier Cross Referencing (PIX) Integration Profile supports two domains: • A Patient Identifier Domain is defined as a single system or a set of interconnected systems that all share a common identification scheme (an identifier and an assignment process to a patient) and issuing authority for patient identifiers. • The Patient Identifier Cross-reference Domain embodies the following assumptions about agreement within the group of individual Identifier Domains: • They have agreed to a set of policies that describe how patient identities will be cross-referenced across participating domains; • They have agreed to a set of processes for administering these policies; • They have agreed to an administration authority for managing these processes and policies.

12. PIX Introduction The Patient Identifier Cross-referencing Integration Profile (PIX) is targeted at healthcare enterprises of a broad range of sizes (hospital, a clinic, a physician office, etc.). It supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains via the following interactions: • The transmission of patient identity information from an identity source to the Patient Identifier Cross-reference Manager. • The ability to access the list(s) of cross-referenced patient identifiers either via a query / response or via update notification.

13. <<broke use cases into two slides>>

14. PIX Use Cases • Use Case: Multiple Identifier Domains within a Single Facility / Enterprise. • Clinician seeks to monitor data across Intensive Care and hospital’s laboratory system • Essentially two different patient identifier domains • Hospital ADT system acts as the Patient Identity Source would provide Patient Identity Feed PIX Manager • Intensive Care system would also send a PIX Feed to the PIX Manager • Subsequently any authorized system could use the PIX Manager to determine alternate identifiers

15. PIX Use Cases • Use Case: Multiple ID Domains Across Cooperating Enterprise • Two hospitals become consolidated and have a single PIX Manager, but two patient registration systems • Cardiology system is aware of PIX Manager. • Performs initial query, and subscribes to receives updates.

16. PIX Process Flow Diagram

17. PIX Transaction Diagram

18. PIX Actors • Actors • Patient Identity Source – Provides notification to the Patient Identifier Cross-reference Manager and Document Registry for any patient identification related events including: creation, updates, merges, etc. • Patient Identifier Cross-reference Consumer – Uses patient identifiers provided by Patient Identity Source to ensure that XDS Documents metadata registered is associated with a known patient and updates patient identity in document metadata by tracking identity change operations (e.g., merge). • Patient Identifier Cross-reference Manager – Serves a well-defined set of Patient Identification Domains. Based on information provided in each Patient Identification Domain by a Patient Identification Source Actor, it manages the cross-referencing of patient identifiers across Patient Identification Domains.

19. PIX Transactions and Options • Transactions • Patient Identity Feed [ITI-8] – Communicates patient information, including corroborating demographic data, after a patient’s identity is established, modified or merged or after the key corroborating demographic data has been modified. • PIX Query [ITI-9] – Request by the Patient Identifier Cross-reference Consumer Actor for a list of patient identifiers that correspond to a patient identifier known by the consumer. • PIX Update Notification [ITI-10] – The Patient Identifier Cross-reference Manager Actor provides notification of updates to patient identifier cross-reference associations to Patient Identifier Cross-reference Consumers that have registered their interest in receiving such notifications. • Options • PIX Update Notification

20. PIX to eMPI Relationship • PIX is compatible with enterprise master patient index systems (eMPI) • Supports both “federated” and “master” topologies • An HL7 v2 ADT stream can act as the Patient Identity Source Actor • The eMPI query function can act as the Patient Identifier Cross-reference Manager actor

21. PIX vs. PIXv3 • PIX v2 vs. PIX v3 • Identical purpose, different underlying standards • HL7 v2 messaging is used for PIX v2 • HL7 v3 messaging is used for PIX v3

22. IHE Profile Grouping • Each actor implementing PIX shall be grouped with the Time Client Actor • Required to manage and resolve conflicts in multiple updates

23. HIE Core Services - PIX/PDQ PIX/PDQ Manager HIE ID: IHI12345 Local ID:1208XYZ Local ID:ABC789 Content Consumers PHR’s XDS Registry XDS Registry HIE ID: IHI12345 Name: William Johnson Documents: ----- Location: ---- Global ID: IHI12345 Name: William Johnson Documents: ----- Location: ---- Global ID: 789 Name: Mary Johnston Documents: ----- Location: ---- HIE ID: 789 Name: Mary Johnston Documents: ----- Location: ---- • Supports HL7 messages • Links all records with HIE AA ID • Updates XDS Registry • Answers queries about patients HIE Core Services HIE ID: IHI12345 Name: William Johnson Documents: ----- Location: ---- HIE Assigning Authority PIX/PDQ Events ATNA –Audit Trail Repository Physician Portal ??? System Radiology System Radiology System LAB System Registration System EHR’s Content Creators

24. PIX Security and Privacy • Grouped with IHE ATNA profile • Recorded as “Patient Record” events

25. References • TBD

26. PDQ – Patient demographics and visit query

27. PDQ Introduction • PDQ = Patient Demographics and Visit Query • PDQ is designed to allow for a query across domains using, as the name implies, demographic information • Status: Final Text?

28. PDQ Problem Statement • The industry needs a standards-based method to provide ways for multiple distributed applications to query a patient information server for a list of patients, based on user-defined search criteria, and retrieve a patient’s demographic (and, optionally, visit or visit-related) information directly into the application.

29. <<finished? Use cases>>

30. PDQ Use Cases • Use Case 1: Patient Information Entering at Bedside • Patient is admitted with partial demographics • Nurse searches for partial or complete name, patient ID, date of birth, bed ID • System returns list of patients for demographic confirmation and selection of correct patient record

31. PDQ Use Cases • Use Case 2: Patient Identity Information Entering in Physician Offices • First visit of a new patient • Nurse needs to register patient, including demographics, in practice management system • Practice is able to access an affiliated hospital’s central patient registry (eMPI) • Nurse looks up patient, using basic demographics, in a hospital’s central patient registry • Nurse selects proper record and updates the physician office practice management system

32. PDQ Use Cases • Use Case 3: Patient Demographics Query in an Enterprise with Multiple Patient ID Domains • Laboratory technician seeks to select correct patient for use by laboratory software application (for use by the lab internal workflow, for billing, and for results distribution) • Lab tech enters basic demographics into laboratory software application • The lab software uses PDQ to query central facility patient registry for demographics • The lab software also retrieves alternate patient identifiers used by other software • The lab tech selects the proper patient and then the lab software application updates its internal records to reflect the correct patient identifiers, and demographics, for subsequent use (internal workflow, billing, and results delivery)

33. PDQ Transaction Diagram

34. PDQ Actors • Patient Demographics Consumer – Requests a list of patients matching a minimal set of demographic (e.g., ID or partial name) and visit criteria from the Patient Demographics Supplier. • Patient Demographics Supplier – Returns demographic and visit information for all patients matching the demographic and visit criteria provided by the Patient Demographics Consumer.

35. PDQ Transactions • Patient Demographics Query [ITI-21] – This transaction involves a request by the Patient Demographics Consumer Actor for information about patients whose demographic data match data provided in the query message. The request is received by the Patient Demographics Supplier Actor. The Patient Demographics Supplier Actor immediately processes the request and returns a response in the form of demographic information for matching patients. • Patient Demographics and Visit Query [ITI-22]– This transaction involves a request by the Patient Demographics Consumer Actor for information about patients whose demographic and visit data match data provided in the query message. The request is received by the Patient Demographics Supplier actor. The Patient Demographics Supplier actor immediately processes the request and returns a response in the form of demographic and visit information for matching patients.

36. <<updated>>

37. PDQ Options • Actor: Patient Demographics Consumer • Option: Patient Demographics and Visit Query • Actor: Patient Demographics Supplier • Option: Patient Demographics and Visit Query

38. PDQ Process Flow(s)

39. PDQ Attributes • Patient Identifier List (R), Patient Name (R), Date/Time of Birth (R2), Administrative Sex (R2), Patient Address (R2), Patient Account Number (R2) • PD1 (Patient Additional Demographics) segment • Patient Class, Assigned Patient, Location, Attending Doctor, Referring Doctor, Consulting Doctor, Hospital Service, Admitting Doctor, Visit Number • PV2 (Patient Visit – Additional Information) segment • QRI (Query Response Instance) segment

40. PDQ Security and Privacy • Paired with ATNA • Creates “Query” Event IDs

41. HIE Core Services - PIX/PDQ PIX/PDQ Manager HIE ID: IHI12345 Local ID:1208XYZ Local ID:ABC789 Content Consumers PHR’s XDS Registry XDS Registry HIE ID: IHI12345 Name: William Johnson Documents: ----- Location: ---- Global ID: IHI12345 Name: William Johnson Documents: ----- Location: ---- Global ID: 789 Name: Mary Johnston Documents: ----- Location: ---- HIE ID: 789 Name: Mary Johnston Documents: ----- Location: ---- • Supports HL7 messages • Links all records with HIE AA ID • Updates XDS Registry • Answers queries about patients HIE Core Services HIE ID: IHI12345 Name: William Johnson Documents: ----- Location: ---- HIE Assigning Authority PIX/PDQ Events ATNA –Audit Trail Repository Physician Portal ??? System Radiology System Radiology System LAB System Registration System EHR’s Content Creators

42. PDQ References • TBD

43. <<new content follows>>

44. Cross-Community Patient Discovery XCPD

45. XCPD Introduction • The Cross-Community Patient Discovery (XCPD) profile supports the means to locate communities which hold patient relevant health data and the translation of patient identifiers across communities holding the same patient’s data. • A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information within the community via an established mechanism. • Facilities/enterprises may host any type of healthcare application such as EHR, PHR, etc.

46. XCPD Status • Relatively new profile • Entered first year of “Trial Implementation” status in 2011 • Deployed by NHIN Exchange participants in 2010 Production Specifications set • Was demonstrated / tested for the first time at the 2011 IHE Connectathon

47. XCPD vs. PDQ • XCPD supports both synchronous and asynchronous methods • Is optimized for cross-community use cases • Supports a health data locator option for sub community support • Supports a reverse query for additional demographics negotiation for better matching

48. XCPD • <covered by karen, sync up with her> • XCPD = Cross Community Patient Discovery • XCDP is designed … • XCPD is different than PDQ in the following ways… • Async, optimized, reverse query, etc.

49. Patient Administration Management PAM

50. PAM Introduction The PAM profile specifies two transactions to fulfill two key missions among applications cooperating in healthcare: • Patient Identity Feed: Maintain consistency of patient demographics (i.e. patient identification, full identity and persons related to the patient) across applications operating in acute care settings as well as in the ambulatory environment. • Patient Encounter Management: Coordinate the exchange of patient account, encounter and location information within and between acute care settings.