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