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