Dave, Our immediate goals at AMPATH are to handle multiple identifiers and possibly do distance comparisons of GPS coordinates. Your's is another good example of another handy matching algorithm. The goal of creating an interface for the algorithm is to allow for developers to create any algorithm that meets their needs. So, instead of trying to solve every problem in the patient matching module, we'll make it easy for devs add customizations. I've spoken with Shaun Grannis and he likes the idea.
While we'll start by introducing a custom algorithms, I'd also like to do the same on the front end – i.e., allow for a custom column (per Shaun, this should be called a "custom trait"), so devs could easily throw classes on the classpath to expand on the list of available traits (columns) as well as the list of possible methods of matching data. This would open the door for popular customizations to eventually be packaged with the module. And, I'd love to see a set of customizations use the scripting interface built into Java (JSR-223<http://jcp.org/aboutJava/communityprocess/final/jsr223/index.html>) to create custom traits & algorithms that could bind the patient and API to a scripting context and execute user-written scripts for truly customizable matching (of course it would need to be efficient, but javax.script defines a CompiledScript<http://docs.oracle.com/javase/6/docs/api/javax/script/CompiledScript.html>… so maybe it's not just a dream). Imagine being able to write your namephonetics algorithm in Groovy or JavaScript and use it within the patient matching module. ;-) Small steps... -Burke On Mon, Feb 27, 2012 at 5:16 PM, Dave Thomas <[email protected]> wrote: > Hi. I haven't followed this discussion very closely but if you're > creating interfaces in the patient matching module, i just wanted to > register the use-case that it would be really cool if there were interfaces > exposed in patient matching that would allow namephonetics to register a > phonetics equivalence test as part of the matching criteria. > > (meaning finding names that are phonetically the same, even if spelled > differently, according to the phonetics structure of the local language) > > d > > > On Mon, Feb 27, 2012 at 10:33 AM, Burke Mamlin <[email protected]>wrote: > >> 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 >>> >> >> ------------------------------ >> 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]
