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. <<added definitions>>

19. 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.

20. 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

21. 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

22. 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

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

24. PIX Workflow(s) • <<Comments from last review: • List one or more typical workflows • Should be a less technical diagram, like the appendix, not a UML sequence diagram • Will the next slide (build) work?>>

25. 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

26. PIX Security and Privacy • <<Describe how security and privacy are implemented for this profile>>

27. PIX Security and Privacy • Grouped with ATNA; recorded as “Patient Record” events

28. References • TBD

29. PDQ – Patient demographics and visit query

30. 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?

31. 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.

32. 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

33. PDQ Use Cases • Use Case 2: Patient Identity Information Entering in Physician Offices

34. PDQ Use Cases • Use Case 3: Patient Demographics Query in an Enterprise with Multiple Patient ID Domains

35. PDQ Transaction Diagram

36. 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.

37. 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.

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

39. PDQ Process Flow(s)

40. 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

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

42. 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

43. PDQ References

44. 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. • Used for the Nationwide Health Information Network Exchange 2010 Patient Discovery Production Specification

45. XCPD Maturity • Relatively new profile, just entering first year of “Trial Implementation” status • Deployed by NHIN Exchange participants • Will be demonstrated for the firs time at the 2011 IHE Connectathon?

46. XCPD Use Case • Use case

47. XCPD Transaction Diagram • Insert transaction diagram from ITI TF

48. XCPD Actors • List and define each XCPD actor • List each XCPD transaction

49. XCPD Options • List and define each XCPD option

50. XCPD Workflow(s) • List one or more typical workflows