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
>
_________________________________________
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]
