XCPI - Cross-Community Patient Identification (likely to be renamed to something like XC Patient Location and Identification) Karen Witting

2 IHE Process Proposals – Fall timeframe – XCPI accepted Use Case Analysis – Winter timeframe – XCPI complete Profiling of standards – Spring timeframe – XCPI just begun Public Comment ready for review – June 1 (30 days) Review of public comments – July Release of Trial Implementation – August

3 Use case analysis Location and Patient Identity sharing Shared/ Voluntary ID available No Location Authority available A Single Location Authority Location Authority Known B1 Location Authority Not Known B2 Multiple Location Authorities C No Shared/ Voluntary ID available Single Location Authority Location Authority Known D1 Location Authority Not Known D2 Multiple Location Authorities E No location Authority Available Correlate IDs with no updates F1 Correlate IDs with updates F2 Hierarchical organizing body G

4 Correlation with and without updates F1 – Correlate IDs without updates Assumes a caching model where requestor caches result of query for 1-3 days. After cache expiration requestor queries again if needed Satisfies a “loose coupling” approach, where there is small patient overlap and infrequent change in patient correlations. F2 – Correlate IDs with updates Assumes an update model where requestor assumes responder will notify of any relevant updates and responder assumes the same. Assumes responder with no match queries all new patients upon first presentation Satisfies a “tight coupling” approach, where there is high overlap in common patients and frequent changes in patient correlation.

5 Considered six transactions QD – This transaction supports the ability to query across communities, specifying demographics and receiving a response indicating whether a matching patient exists in the responding community. The result is a correlation of patients across the requestor and responder communities. That correlation can be used only on the requestor side or on both sides. QI – This transaction supports the ability to query across communities, specifying a patient identifier only and receiving a response indicating whether a matching patient exists in the responding community. The result is a correlation of patients across the requestor and responder communities. That correlation can be used only on the requestor side or on both sides. U – This transaction supports the ability to manage updates of patient identifiers and demographics that have been previously correlated. QDL – This transaction supports the ability to query a Location Authority, specifying demographics and receiving a response listing communities which may have data associated with the patient described by the demographics. For each community returned, a patient identifier is included to be used for that community. QIL – This transaction supports the ability to query a Location Authority, specifying a patient identifier and receiving a response listing communities which may have data associated with the patient described by the identifier. For each community returned, a patient identifier is included to be used for that community. QDLA – This transaction supports the ability to query across communities, specifying demographics and receiving a response indicating whether the queried community is a Location Authority for the patient described by the demographics. A positive response includes a patient identifier for the patient which can be used in a subsequent QIL transaction.

6 Six Transactions Considered WHOSentResponseResult QD From/to all known communities Demographics and identifiers for requesting community Demographics and identifiers for matches in responding community Correlation of patients across the requestor and responder communities QI From/to all known communities Patient Identifier (shared, voluntary, etc). Whether responding community knows a patient with that ID Location of shared/voluntary identified patient U From/to communities where QD correlation previously established New demographics, merge, link, unmerge, unlink, other as identified New correlation?Correlation of patients updated QDL Location AuthorityDemographicsList of communities (including local identifiers) which may have information about the identified patient Requestor has information of location and local identification of patient QIL Location AuthorityPatient Identifier (shared, voluntary, etc). List of communities (including local identifiers) which may have information about the identified patient Requestor has information of location and local identification of patient QDLA From/to all known communities DemographicsIndication if responder is a Location Authority for that patient. Includes patient ID to use for subsequent QIL Requestor discovers Location Authority for specific patient

7 Mapping of use cases to transactions Use CaseTransactions Used G: Hierarchical organizing body availableITI-30 Patient Identity Management ITI-9 PIX Query F1: Correlation of IDs with no updatesQD F2: Correlation of IDs with updatesQD, U (defer update transaction) A: Shared/Voluntary ID with no Location AuthorityQI (merged into QD) B1: Shared/Voluntary ID with single Location Authority knownQIL B2: Shared/Voluntary ID with single Location Authority not known QIL C: Shared/Voluntary ID with multiple Location AuthorityQIL D1: No shared/voluntary ID with single Location Authority known QDL (replace with QDLA + QIL) D2: No shared/voluntary ID with single Location Authority not known QDLA, QIL E: No shared/voluntary ID with multiple Location AuthoritiesQDLA, QIL

8 Conclusions Concluded first year of profile would include QD, QIL and QDLA (explanations follow) Case A: QD and QI are similar enough to be combined into one transaction. The transaction would require either a patient identifier (supporting the QI case) or demographics plus patient identifier (supporting the QD case). Case D1: QDL is used only in case D1 and can be replaced by a sequence of QDLA followed by QIL. Although this is less efficient it was felt that the cost of the extra transaction was acceptable in this environment. Case F2: The environment which seeks to actively manage correlation of patient identifiers across communities must consider and account for many complex interactions, error and edge cases. In particular, cases where the communities do not agree on the merging or linking (or unmerging/unlinking) and where patient demographics changes may not resolve to the same correlation as found previously result in complex paths and considerations that are beyond the possible scope of the first verion of this profile. For that reason we have chosen not to profile the Update transaction at this time.

9 QD specification – work in progress Start with IHE Patient Demographics Query HL7 V3 (ITI-47) – HL7 V3 Patient Registry Find Candidates Query (PRPA_IN201305UV02) and Response (PRPA_IN201306UV02) which is supported by the Patient Registry Query by Demographics (PRPA_MT201306UV02)message. Changes from IHE PDQ Query: – –No use of continuation – –Both synchronous and asynchronous support included. – –Require search parameters Name and Birthtime HL7 V3 entities unless its is only a patient identifier query. – –Add mothers maiden name to search parameters – –Designate one of the identifiers in “LivingSubjectId” HL7 V3 field as the ID usable by responder in XCA Queries. – –Do not use OtherIDsScopingOrganization – –Add optional use of error response to designate attributes that, if specified, may yield a match – in effect a “maybe” response with a hint – –Add birth place in response (optional) – –Responder required to respond with a small set of “best” (PDQ requires all)