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