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