Patient Matching. Process Reviewed secondary (e.g. white papers) and primary literature on patient...

Patient Matching

Process

• Reviewed secondary (e.g. white papers) and primary literature on patient matching

• Series of teleconferences to establish scope, develop a framework and populate the framework

Assumptions

• There are multiple use cases with different trade-offs for sensitivity and specificity – our Summer Camp focus on patient care use case

• Establishing acceptable false positive rates is a policy and perhaps local decision based on what is possible/available in a market

• Focused on guidance around the EHR

Finding/Caveats

• The data necessary to provide explicit guidance on which patient attributes to “require” or for which to improve quality

• Some patient attributes (e.g.

e-mail or zip code) vary

significantly over time

Principles

• Specificity more critical than sensitivity – false positive rate will be critical

• Don’t preclude new attributes from being added to matching process

Flow Chart

QuerySource*

Query Responder*

Query Message• Core attributes• Optional attributes

Query Response Message• Matched patients• Match metadata

Captures and ensures quality of

data needed to create query

message

Characterizes population of patients being

matched

* Note that an EMR may serve as both or either a query source and a query responder

Matching Fields

• Core– Name (last, first, middle initial)– Birth date– Gender (administrative?)

• Menu (some required to successfully match)– Address including zip (current and past)– Social security number– Maiden name– Full middle name– Healthcare provider (individual or institutional)– Visit information– Allow other assigned identifiers to support evolution

Data Quality

• Rational– Garbage-in Garbage-out– Align efforts to improve data with the importance of the data for

matching (optimize value)• Quality “assurance”

– Consistent method to identify missing/unavailable data, approximate values or questionable values

– Apply edits on a field by field basis• Valid dates• No future dates• No SS# sub-fields with all 0s or all 9s• Check that zip code is consistent with street address

– Apply edits on a cross-field basis• Check whether first name and gender are concordant

Data Formats / Content

• Build from IHE PDQ and XCDP(?) implementation guides– Expand on guidance for name structures especially Hispanic

and Asian names– Add option to provide dates along with time variant data (e.g. zip

codes, telephone numbers)

Match Quality Reporting

• What is reasonable to return with the matched patients?– Confidence level– Commonly occurring identifier flag

References

• Perspectives on Patient Matching: Approaches, Findings, and Challenges

• http://www.himss.org/content/files/PrivacySecurity/PIIWhitePaper.pdf

• http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Patient_Demo_Query_2004_08-15.pdf

• http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XCPD_PC_2009-08-10.pdf