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: A system (manual or automated) that creates identifiers for objects (patients, transactions, etc.) that are normally unique within a specified domain. XDS Affinity Domain: 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)

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. PIX Patient identity cross-referencing

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: 1.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. 2.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: 1.The transmission of patient identity information from an identity source to the Patient Identifier Cross- reference Manager. 2.The ability to access the list(s) of cross-referenced patient identifiers either via a query / response or via update notification.

13. >

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

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

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

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

42. PDQ References TBD

43. >

44. XCPD Cross-Community Patient Discovery

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 XCPD = Cross Community Patient Discovery XCDP is designed … XCPD is different than PDQ in the following ways… –Async, optimized, reverse query, etc.

49. PAM Patient Administration Management

50. PAM Introduction The PAM profile specifies two transactions to fulfill two key missions among applications cooperating in healthcare: 1.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. 2.Patient Encounter Management: Coordinate the exchange of patient account, encounter and location information within and between acute care settings.

51. PAM Introduction PAM provide sets of event-triggered messages, notifying the creation and update of patient administrative data. Each transaction involves a pair of (Supplier, Consumer) Actors. Transaction Patient Identity Feed operates in a centralized manner (one Supplier application providing a number of Consumers). Transaction Patient Encounter Management can work in centralized mode as well as in peer to peer mode (Several applications cooperating as peers, each one playing alternatively Supplier and Consumer roles). Transaction Patient Encounter Management can be self contained in a sense that the Patient Encounter Supplier sends both patient encounter information and patient identity and demographics information (in the context of the encounter data) to the Patient Encounter Consumer. In addition, this transaction also allows the Patient Encounter Supplier to send messages to the Patient Encounter Consumer for patient identity maintenance in the encounter context, including patient update and identity merge.

52. PAM Introduction Supports Efficiency of Patient Care Prevents manual data entry errors by ensuring that each piece of patient data or encounter data is entered only once and made available to any application that needs it. Supports a better cooperation between clinical, administrative and ancillary applications, based on a common patient identification and accurate patient demographics. Notifies in real time applications of acute care settings with patient arrivals, movements and departures, planned or effective, which globally improves the efficiency of the services provided by the teams running these applications. Synchronizes the correction of human errors (merge or update patient records, update patient transfer) between all the applications that have been affected by these errors.

53. PAM Use Cases Use Case: Patient Identity Management Covered by Transaction Patient Identity Feed, which supports the following notifications both in acute care and ambulatory environment: –Creation of a new patient demographic record with patient identifier assigned, full identity, related actors (doctor, guarantor, next of kin), qualification of the reliability of the patient identity (e.g. unknown/default date of birth). –Creation of a temporary identification and record for an unknown patient. –Update patient demographic record. –Merge two patient demographic records into one. –Link or Unlink two patient demographic records.

54. PAM Use Cases Use Case: Patient Encounter Management Covered by Transaction Patient Encounter Management, which supports the following sets of notification messages in the context of acute care settings: –Basic mandatory subset: Create, update or close inpatient/outpatient encounter; update patient information ; Merge patient records. –Inpatient/outpatient encounter management option: Pre-admit inpatient, change patient class, transfer, and the cancellations thereof. –Pending Event Management Option: Pending admit, transfer or discharge, and the cancellations thereof. –Advanced Encounter Management Option: Manage leaves of absence, changes of attending doctor, updates of account. –Temporary Patient Transfers Tracking Option: Tracks patient moves to and from temporary locations such as radiotherapy, scanner, EKG, and dialysis. –Historic Movement Management Option: Adds the capability to cancel or update safely any Movement. The major interest of this option is to enable healthcare provision applications to link their acts to the proper patient situation and location.

55. >

56. PAM Introduction The Patient Administration Management Integration Profile establishes the continuity and integrity of patient data, and additional information such as related persons (primary caregiver, guarantor, next of kin, etc.). It coordinates the exchange of patient registration and update information among systems that need to be able to provide current information regarding a patient‘s encounter status and location. This profile supports ambulatory and acute care use cases including patient identity feed, admission and discharge, and transfer and encounter management, as well as explicit and precise error reporting and application acknowledgment. The PAM profile supports two patient encounter management scenarios: either one single central patient registration system serving the entire institution, or multiple patient registration systems collaborating as peers serving different clinical settings in an institution.

57. >

58. PAM Process Flow Diagram

59. PAM Transaction Diagram Patient Demographics Supplier Patient Demographics Consumer Patient Identity Management (ITI-30) Patient Encounter Supplier Patient Encounter Consumer Patient Encounter Management (ITI-31)

60. PAM Actors Actors –Patient Demographics Supplier – TBD –Patient Demographics Consumer – TBD –Patient Encounter Supplier – TBD –Patient Encounter Consumer – TBD

61. >

62. PAM 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

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

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

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

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

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

68. References TBD

69. References TBD

71. Other topics??

72. August 18, 2005 IHE Technical Webinar 72 IHE ITI Integration Profile XDS: Clinical Information Sharing in RHIO US Exam System 14355 Physician Office EHR System A87631 Teaching Hospital XDS Clinical Affinity Domain Community Clinic Lab Info. System PACS L-716 PACS XAD Patient Identity Source M8354673993 Retrieve Document Provide & Register Register Query Document Patient Identity Feed Query Documen t Retrieve Document Provide & Register Register Provide & Register Register Retrieve Document Query Documen t Document Registry Document Repository ED Application In order to publish or query clinical documents in XDS Affinity Domain (XAD), applications need to look-up XAD Patient ID using their local patient information, e.g., Patient ID in local domain and demographics

73. August 18, 2005 IHE Technical Webinar 73 Look-Up XDS Affinity Domain Patient ID with Local PIX Service US Exam System 14355 Physician Office EHR System A87631 Teaching Hospital XDS Clinical Affinity Domain Community Clinic Lab Info. System PACS L-716 PACS XAD Patient Identity Source M8354673993 Retrieve Document Provide & Register Register Query Document Patient Identity Feed Document Registry Document Repository ED Application A87631 M8354673993 14355 L-716 M8354673993 Patient Identity Feed PIX Query

74. August 18, 2005 IHE Technical Webinar 74 Look-Up XDS Affinity Domain Patient ID with Affinity Domain PIX Service US Exam System 14355 Physician Office EHR System A87631 Teaching Hospital XDS Clinical Affinity Domain Community Clinic Lab Info. System PACS L-716 PACS XAD Patient Identity Source M8354673993 Retrieve Document Provide & Register Register Query Document Patient Identity Feed Document Registry Document Repository ED Application 14355 M8354673993 L-716 A87631 Patient Identity Feed PIX Query Patient Identity Feed M8354673993 A87631 14355 L-716

75. August 18, 2005 IHE Technical Webinar 75 Query Affinity Domain PDQ Service for XDS Affinity Domain Patient ID US Exam System 14355 Physician Office EHR System A87631 Teaching Hospital XDS Clinical Affinity Domain Community Clinic Lab Info. System PACS L-716 PACS XAD Patient Identity Source M8354673993 Retrieve Document Provide & Register Register Query Document Patient Identity Feed Document Registry Document Repository ED Application PDQ Query to Acquire XAD Patient ID Patient Demographics Supplier

76. August 18, 2005 IHE Technical Webinar 76 IHE IT Infrastructure Integration Profiles Provide a Solid Foundation for EHR Management Cross-enterprise Patient Health Information Management Architectural Principles: A Patient Information Source administers patient records (demographics) and manages a Patient Identification Domain to identify these patient records on that domain Patient ID is assigned / maintained within a managed Patient Identification Domain Search patient records (in a patient information source) → PDQ Integration Profile Look-up Patient ID in federated domains → PIX Integration Profile Locate healthcare information (documents or services) → XDS Integration Profile

77. August 18, 2005 IHE Technical Webinar 77 IHE PIX / PDQ Profiles Implementation Considerations Master Patient ID Domain Administration and Service Functions PIX Notification Service PIX Query Service PDQ Service Enhanced PDQ Service MPI Service Patient Identity Source HL7 Service defined in IHE Technical Framework Service out of IHE scope Patient Identity Feed Service

78. August 18, 2005 IHE Technical Webinar 78 IHE ITI Integration Profile XDS: Clinical Information Sharing in RHIO US Exam System 14355 Physician Office EHR System A87631 Teaching Hospital XDS Clinical Affinity Domain Community Clinic Lab Info. System PACS L-716 PACS XAD Patient Identity Source M8354673993 Retrieve Document Provide & Register Register Query Document Patient Identity Feed Query Documen t Retrieve Document Provide & Register Register Provide & Register Register Retrieve Document Query Documen t Document Registry Document Repository ED Application In order to publish or query clinical documents in XDS Affinity Domain (XAD), applications need to look-up XAD Patient ID using their local patient information, e.g., Patient ID in local domain and demographics

79. August 18, 2005 IHE Technical Webinar 79 Look-Up XDS Affinity Domain Patient ID with Local PIX Service US Exam System 14355 Physician Office EHR System A87631 Teaching Hospital XDS Clinical Affinity Domain Community Clinic Lab Info. System PACS L-716 PACS XAD Patient Identity Source M8354673993 Retrieve Document Provide & Register Register Query Document Patient Identity Feed Document Registry Document Repository ED Application A87631 M8354673993 14355 L-716 M8354673993 Patient Identity Feed PIX Query

80. August 18, 2005 IHE Technical Webinar 80 Look-Up XDS Affinity Domain Patient ID with Affinity Domain PIX Service US Exam System 14355 Physician Office EHR System A87631 Teaching Hospital XDS Clinical Affinity Domain Community Clinic Lab Info. System PACS L-716 PACS XAD Patient Identity Source M8354673993 Retrieve Document Provide & Register Register Query Document Patient Identity Feed Document Registry Document Repository ED Application 14355 M8354673993 L-716 A87631 Patient Identity Feed PIX Query Patient Identity Feed M8354673993 A87631 14355 L-716

81. August 18, 2005 IHE Technical Webinar 81 Query Affinity Domain PDQ Service for XDS Affinity Domain Patient ID US Exam System 14355 Physician Office EHR System A87631 Teaching Hospital XDS Clinical Affinity Domain Community Clinic Lab Info. System PACS L-716 PACS XAD Patient Identity Source M8354673993 Retrieve Document Provide & Register Register Query Document Patient Identity Feed Document Registry Document Repository ED Application PDQ Query to Acquire XAD Patient ID Patient Demographics Supplier

82. August 18, 2005 IHE Technical Webinar 82 IHE IT Infrastructure Integration Profiles Provide a Solid Foundation for EHR Management Cross-enterprise Patient Health Information Management Architectural Principles: A Patient Information Source administers patient records (demographics) and manages a Patient Identification Domain to identify these patient records on that domain Patient ID is assigned / maintained within a managed Patient Identification Domain Search patient records (in a patient information source) → PDQ Integration Profile Look-up Patient ID in federated domains → PIX Integration Profile Locate healthcare information (documents or services) → XDS Integration Profile

83. August 18, 2005 IHE Technical Webinar 83 IHE PIX / PDQ Profiles Implementation Considerations Master Patient ID Domain Administration and Service Functions PIX Notification Service PIX Query Service PDQ Service Enhanced PDQ Service MPI Service Patient Identity Source HL7 Service defined in IHE Technical Framework Service out of IHE scope Patient Identity Feed Service