All we need (at least to get started) is for the algorithm that is already
stored in the database to allow for custom values – e.g.,
"ke.or.ampath.matching.FooBarMatchSimilarityAlgorithm". We will supply our
own algorithms on the classpath. As long as the patient matching module
calls algorithm.*getMatchSimilarity(v1,v2)* when comparing values, we're
good.
Eventually, we'd like to something similar with column definitions, e.g.
something like:
interface CustomColumn {
public String getName();
public String getValue(Patient patient);
}
But we can focus on the algorithm first, since it will solve our immediate
problems. As long as we can get agreement on a patch, then AMPATH can
apply the patch locally to move forward with custom algorithms while the
patient matching module is being updated.
Cheers,
-Burke
On Mon, Feb 27, 2012 at 1:03 PM, Suranga Kasthurirathne <
[email protected]> wrote:
>
> Hi,
>
> This sounds quite practical to me. I understand what you're tying to do.
> (of course, i'm not THE top expert; we'll need to consult with Dr, Shaun
> too.)
> In regard to improving the MatchResult class, I think that we should
> follow the second plan that Dr. Burke suggested.
> However the question is, do we need database support for this
> functionality ? I don't think so.
>
> In response to Jeremy's questions, I feel that these changes can
> be fitted into the current design quite easily.
> And also ( Pending Dr. Shauns comments) I feel that these changes can go
> into the trunk itself.
> Looking at the possibility of custom columns; once again, this is
> possible, but not quite easy. It will need some re-factoring. And also,
> where are we going to store information on the custom columns? Be it either
> a flat file or a database, we're still going to need some major changes.
> And finally, will creating custom columns affect our calculations in any
> way ? there are a lot of calculations happening under the hood, so we'll
> need to check that out as well.
>
> I'd like to help you out with this in any way that I can.
>
>
>
>
> On Mon, Feb 27, 2012 at 9:11 PM, Suranga Kasthurirathne <
> [email protected]> wrote:
>
>> Hi,
>>
>> Im on a bus right now, so I could not go through the mails properly yet.
>> I will try to come up with some sensible comments as soon as possible :-)
>> On 27 Feb 2012 20:22, "Burke Mamlin" <[email protected]> wrote:
>>
>>> More specifically, we'd like to refactor
>>> MatchResult.*getSimilarityScore(String
>>> demographic)*<https://source.openmrs.org/browse/Modules/patientmatching/src/org/regenstrief/linkage/MatchResult.java?r=25928&r=22126#to164>so
>>> that it uses an interface instead of a switch statement to match values.
>>>
>>> For example:
>>>
>>> interface MatchSimilarityAlgorithm {
>>> public String getName();
>>> public double getMatchSimilarity(String val1, String val2);
>>> }
>>>
>>> then creating classes like:
>>>
>>> class ExactMatchSimilarity implements MatchSimilarityAlgorithm {
>>> public String getName() {
>>> return "Exact Match";
>>> }
>>> public double getMatchSimilarity(String val1, String val2) {
>>> return StringMatch.getExactMatchSimilarity(val1, val2);
>>> }
>>> }
>>>
>>> class LCSMatchSimiliarity implements MatchSimilarityAlgorithm {
>>> public String getName() {
>>> return "Longest Common Subsequence";
>>> }
>>> public double getMatchSimilarity(String val1, String val2) {
>>> return StringMatch.getLCSMatchSimilarity(val1, val2);
>>> }
>>> }
>>>
>>> etc...
>>>
>>> This would make algorithm a MatchSiimilarityAlgorithm instead of a
>>> String. The switch statement in MatchResult.*getSimilarityScore(String)
>>> * can then be replaced with:
>>>
>>> return algorithm.getSimilarityScore(val1, val2);
>>>
>>> This would allow us to introduce new algorithms. Of course, the UI
>>> would need some minor refactoring to use the MatchSimilarityAlgorithm.*
>>> getName()* method to get names of algoirthms.
>>>
>>> If those changes seem to bold at first, then a quicker step in the
>>> direction would be to introduce the interface, allow algorithm to be a
>>> class name, and refactor the last (default) case in the switch statement to
>>> something like:
>>>
>>> default:
>>> try {
>>> Class clazz = Class.forName(algorithm);
>>> if (clazz instanceof MatchSimilarityAlgorithm)
>>> return ((MatchSimilarityAlgorithm)algorithm)
>>> .getSimilarityScore(val1, val2);
>>> } catch (ClassNotFoundException e) {
>>> return 0;
>>>
>>> This wouldn't fully customize algorithms, but would at least allow us to
>>> sneak in our own algorithms during matching.
>>>
>>> Cheers,
>>>
>>> -Burke
>>>
>>> On Mon, Feb 27, 2012 at 8:49 AM, Jeremy Keiper <[email protected]>wrote:
>>>
>>>> Suranga, James, Burke, Shaun, etc -
>>>>
>>>> AMPATH has a development-backed immediate interest in these custom
>>>> column definitions for acquiring and comparing attributes of patient data.
>>>> If there is any way that this can be fitted into the current design, could
>>>> we get some direction on how it could work and whether the Patient Matching
>>>> Module authors would like to incorporate it to trunk or allow us to branch
>>>> it for those purposes?
>>>>
>>>> Thanks!
>>>>
>>>> Jeremy Keiper
>>>> OpenMRS Core Developer
>>>> AMPATH / IU-Kenya Support
>>>>
>>>>
>>>>
>>>> On Tue, Feb 21, 2012 at 10:00 PM, Rajib Sengupta
>>>> <[email protected]>wrote:
>>>>
>>>>> Hello All,
>>>>> As new implementor of openMRS, I cannot resist, but to chime in this
>>>>> discussion.
>>>>>
>>>>> If the web UI of patient matching can be configurable, it will be
>>>>> indeed a great feature. Primarily this will help implementation team which
>>>>> is low with pure developer resources and for implementations in new
>>>>> geographic regions where the patient matching can be based on different
>>>>> patient attributes, that is not available in the current ui, out of the
>>>>> box.
>>>>>
>>>>> Again, this is just our opinion and want to share it with the
>>>>> development team so that development items can be prioritized from an user
>>>>> usability perspective.
>>>>>
>>>>> Thanks,
>>>>> Rajib
>>>>>
>>>>> *From:* Suranga Kasthurirathne <[email protected]>
>>>>> *To:* [email protected]
>>>>> *Sent:* Tuesday, February 21, 2012 12:21 PM
>>>>> *Subject:* Re: [OPENMRS-DEV] Latest improvements to the Patient
>>>>> Matching module
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I agree. Right now, the web based ui that you'll get by loading the
>>>>> module doesn't actually let you make use of the extensive (really really
>>>>> really extensive) functionality the patientmatching module can offer. If
>>>>> fact, sometimes I feel that the web ui is tying to hide its true
>>>>> awesomeness.
>>>>> If the web ui let you make use of all the extensive functionality that
>>>>> the module offers, it would be one of the top favorite of our modules.
>>>>> However that said, i'm not sure which of the two above
>>>>> mentioned efforts should get priority over the other. I'm OK with whatever
>>>>> the experts agree on :-)
>>>>>
>>>>>
>>>>> On Tue, Feb 21, 2012 at 11:24 AM, Darius Jazayeri <
>>>>> [email protected]> wrote:
>>>>>
>>>>> It certainly has potential as a GSoC project.
>>>>>
>>>>> That said, my main concern with the Patient Matching module has been
>>>>> that the UI is not easily approachable by anyone who hasn't built up some
>>>>> domain knowledge on patient matching. I believe this has been improved,
>>>>> though I'm not sure how much. Making it usable by an admin with only basic
>>>>> OpenMRS knowledge would be a higher priority for me. (Unless that's
>>>>> already
>>>>> been done!)
>>>>>
>>>>> -Darius
>>>>>
>>>>>
>>>>> On Mon, Feb 20, 2012 at 8:50 PM, Suranga Kasthurirathne <
>>>>> [email protected]> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> To the best of my knowledge, the patient Matching module provides
>>>>> multiple ways of reading in data (txt files, one or two databases)
>>>>> but doesn't really provide you with an interface for data columns.
>>>>> So right now, it seems to be that we really can't add derived columns
>>>>> like the ones you and Darius mentioned.
>>>>>
>>>>> However, it does provide an interface for Analyzers (which is
>>>>> comparable to algorithms), so users can write up their own analyzers if
>>>>> they wish to do so.
>>>>> I understand the functionality that you are talking about, and I
>>>>> realize that its an important and useful feature.
>>>>> Possibly, this will be easier to implement once the database changes
>>>>> are in.
>>>>>
>>>>> I will talk to James regarding this, and get his feedback on my
>>>>> comments....
>>>>>
>>>>> @Dr. Burke, @Darius, mmm.... does this sound like a good GSOC idea to
>>>>> you ? maybe Dr. Grannis will also be interested :-)
>>>>>
>>>>>
>>>>> Thanks and best regards,
>>>>> Suranga
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 21, 2012 at 5:44 AM, Darius Jazayeri <
>>>>> [email protected]> wrote:
>>>>>
>>>>> What Burke describes, with the ability to write those as groovy and
>>>>> store them in the DB would be pretty neat. :-)
>>>>>
>>>>> -Darius
>>>>>
>>>>>
>>>>> On Mon, Feb 20, 2012 at 2:08 PM, Burke Mamlin <[email protected]
>>>>> > wrote:
>>>>>
>>>>> Suranga,
>>>>>
>>>>> Does the patient matching module provide interfaces for a data source
>>>>> columns and/or algorithms so implementations could define custom column(s)
>>>>> and/or custom comparison algorithm(s)? For example, I'm imagining
>>>>> something like:
>>>>>
>>>>> interface DataSourceColumn {
>>>>> public String name();
>>>>> public String getValue(Patient patient);
>>>>> }
>>>>>
>>>>> interface Algorithm {
>>>>> public String getName();
>>>>> public float match(String a, String b);
>>>>> }
>>>>>
>>>>> Assuming the out-of-the-box patient demographics implement the
>>>>> DataSourceColumn interface, it would be easy to add new derived columns
>>>>> (e.g., a region-specific soundex algorithm, a column that concatenates all
>>>>> patient identifiers, or a column that combines latitude & longitude from
>>>>> address). And assuming that "Exact Match" and other out-of-the-box
>>>>> comparison algorithms imlemented the Algorithm interface, then it would be
>>>>> easy to add new custom algorithms (e.g., matching GPS coordinates based on
>>>>> computed distance).
>>>>>
>>>>> Cheers,
>>>>>
>>>>> -Burke
>>>>>
>>>>> On Mon, Feb 20, 2012 at 3:15 AM, Suranga Kasthurirathne <
>>>>> [email protected]> wrote:
>>>>>
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We have just committed some important changes to the patientMatching
>>>>> module <https://wiki.openmrs.org/display/docs/Patient+Matching+Module>
>>>>> .
>>>>>
>>>>> These changes are part of our efforts to move user generated patient
>>>>> matching report details from a flat file system to a database. We have not
>>>>> completed the entire effort, but have made a reasonable amount of
>>>>> progress. At this given moment, the enhancements we made will let you
>>>>> store
>>>>> user defined patient matching strategies in the database. Efforts to
>>>>> store
>>>>> the entire user generated report in the database are still underway.
>>>>> Please note that following these changes, user defined strategies are
>>>>> now stored in database tables, and not in the existing config.xml file.
>>>>>
>>>>> However, do note that this effort is still at an experimental level,
>>>>> so do be careful if you decide to use the latest build.
>>>>>
>>>>> --
>>>>> On behalf of the PatientMatching team,
>>>>> Suranga
>>>>>
>>>>> Click here to
>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>>>> OpenMRS Developers' mailing list
>>>>>
>>>>>
>>>>> Click here to
>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>>>> OpenMRS Developers' mailing list
>>>>>
>>>>>
>>>>> Click here to
>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>>>> OpenMRS Developers' mailing list
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards,
>>>>>
>>>>> Suranga
>>>>>
>>>>> Click here to
>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>>>> OpenMRS Developers' mailing list
>>>>>
>>>>>
>>>>> Click here to
>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>>>> OpenMRS Developers' mailing list
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards,
>>>>>
>>>>> Suranga
>>>>>
>>>>> Click here to
>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>>>> OpenMRS Developers' mailing list
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> Click here to
>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>>>> OpenMRS Developers' mailing list
>>>>>
>>>>
>>>> ------------------------------
>>>> Click here to
>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>>> OpenMRS Developers' mailing list
>>>>
>>>
>>> ------------------------------
>>> Click here to
>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>> OpenMRS Developers' mailing list
>>
>>
>
>
> --
> Best Regards,
>
> Suranga
>
> ------------------------------
> Click here to
> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
> OpenMRS Developers' mailing list
>
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
