The LinkResult class captures information measuring the quality of match between an incoming patient record and an existing Person Cluster. While our algorithm uses median-aggregated tracking statistics to make the best determination of match, this information is somewhat opaque to the user. For example, if a record scored as a possible match to a Cluster, how does the overall accumulated log odds points break down across feature? If I'm a user, I want to know which features scored the highest and by what distribution so that I can make an informed decision around merging or not merging an incoming record.
The scope of this ticket is to think through and design a user-reporting mechanism for the LinkResult class. Previously, this was to be the context property mentioned in the original ticket, but there were some nuances and differences of purpose that merited breaking this out on its own. The handler of this ticket should think through the two approaches outlined in the original ticket and weigh the benefits of implementing the different types of feature comparison reporting to the user. If the handler doesn't come up with another solution or think of another way to report information (which is totally fine), the handler should implement option 2 in the linked ticket (report the median feature evaluation for each field).
The
LinkResultclass captures information measuring the quality of match between an incoming patient record and an existing Person Cluster. While our algorithm uses median-aggregated tracking statistics to make the best determination of match, this information is somewhat opaque to the user. For example, if a record scored as apossiblematch to a Cluster, how does the overall accumulated log odds points break down across feature? If I'm a user, I want to know which features scored the highest and by what distribution so that I can make an informed decision around merging or not merging an incoming record.The scope of this ticket is to think through and design a user-reporting mechanism for the
LinkResultclass. Previously, this was to be thecontextproperty mentioned in the original ticket, but there were some nuances and differences of purpose that merited breaking this out on its own. The handler of this ticket should think through the two approaches outlined in the original ticket and weigh the benefits of implementing the different types of feature comparison reporting to the user. If the handler doesn't come up with another solution or think of another way to report information (which is totally fine), the handler should implement option 2 in the linked ticket (report the median feature evaluation for each field).