1 / 11

Patient Matching

Patient Matching . Work in Progress. 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. Process.

blanca
Download Presentation

Patient Matching

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Patient Matching Work in Progress

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

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

  4. 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 Finding/Caveats

  5. Specificity more critical than sensitivity – false positive rate will be critical Don’t preclude new attributes from being added to matching process Principles

  6. Flow Chart Captures and ensures quality of data needed to create query message Characterizes population of patients being matched Query Source* • Query Message • Core attributes • Optional attributes Query Responder* • Query Response Message • Matched patients • Match metadata * Note that an EMR may serve as both or either a query source and a query responder

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

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

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

  10. Match Quality Reporting Work in Progress • What is reasonable to return with the matched patients? • Confidence level • Commonly occurring identifier flag

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

More Related