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