Can be done in a module, then accessed through <object>Properties or complex obs beginning 1.9
From: [email protected] [mailto:[email protected]] On Behalf Of Rowan Seymour Sent: Tuesday, October 25, 2011 8:15 AM To: [email protected] Subject: Re: [OPENMRS-DEV] Student module ideas @Roger cool idea but perhaps beyond our scope as it would be a modification to OpenMRS core @Joaquín I wonder if that shouldn't be implemented as an Eclipse plugin rather than an OpenMRS module? It sounds like a developer tool rather than something for OpenMRS users. I wonder if such a tool already exists for Spring based applications? On 24 October 2011 15:01, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: How about an "anatomical drawing" custom datatype? There would be selectable "canvases" which would be line drawings of different parts of the anatomy (whole body back and front; hand/arm top/bottom; retinas; etc.). The user could draw on the selected canvas, adding lines (with color), areas (with color and texture), text (boxes and callouts). From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Rowan Seymour Sent: Monday, October 24, 2011 2:34 AM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] Student module ideas Christian, Joaquín Thanks for these - I think we have two very suitable module ideas here - I'll get back to you for more details shortly. On 24 October 2011 05:53, Christian Neumann <[email protected]<mailto:[email protected]>> wrote: Another idea is a 'Know your OpenMRS database'. Using OpenMRS for a couple of years and having multiple responsible persons touching it, we have accumulated quite a few different encounter types and obs. It is not straight forward to see which encounter types have which and how many obs's and underlying concepts. An 'database archeology' tool that prints out the number of encounters per encounter type, and the numbers of obs with matching concepts per encounter type will be helpful. Maybe together with the first and last time an encounter type was used. This would help a lot to understand and to tidy up the database. christian On Oct 22, 2011, at 2:35 PM, Joaquín Blaya wrote: Rowan, other ideas that occur to me 1. Improving the database messaging module so that you can ask it which labels are missing for a specific language. For extra credit, it would then list those for you and you would be able to type in the translation and it would automatically save that to the appropriate messages.properties file. Something similar to the ResourceBundle tool for Eclipse http://sourceforge.net/projects/eclipse-rbe/ 2. Perhaps fixing tickets to make more modules functional with 1.8? I have two modules that work with 1.6, but not with 1.8. Joaquín ___________________________________________________________________ Gerente de Desarrollo, eHealth Systems<http://www.ehs.cl/> Research Fellow, Escuela de Medicina de Harvard<http://hms.harvard.edu/> Moderador, GHDOnline.org<http://www.ghdonline.org/> On Fri, Oct 21, 2011 at 9:58 AM, Christian Neumann <[email protected]<mailto:[email protected]>> wrote: Appointment date suggestion This would be another client-side hack or modification to HTML form entry so that appointment dates could be suggested based on some logic (from Christian Neumann) I think this could also be done 'properly' in HFE. The obs tag might be able to take additional validation rules as parameters for date obs. I can see these use cases: - Relative to the encounter date the appointment date should not be more than x months in the future. - The appointment date must be greater than the encounter date. - The appointment date can be restricted to certain weekdays (not all the clinics offer service all days during the week). Ideally this is tight to the encounter location. - More difficult will be the validation based on other obs or drugs. If a patient only gets drugs for 20 days, the appointment date can't be much later. christian ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list -- Rowan Seymour tel: +250 783835665<tel:%2B250%20783835665> http://twitter.com/rowanseymour ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list -- Rowan Seymour tel: +250 783835665 http://twitter.com/rowanseymour ________________________________ Click here to unsubscribe<mailto:[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]
