Karen Witting

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

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

7. Mapping of use cases to transactions

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)