This page is meant to be a hatching ground for project ideas. A quick statement about what the project could be is all that is needed here.

Potential Projects

• Generify some of the Rwanda or AMPATH specific modules - Ben 10:18, 12 March 2009 (EDT)
• Build standard tooling in core web layer to display all our domain objects. http://openmrs.org/wiki/Conventions#User_Interface - Djazayeri 10:24, 12 March 2009 (EDT)
• Rename formentry module to infopathformentry - Ben 14:12, 12 March 2009 (EDT)
• Support for mini-encounters in OpenMRS, most likely implemented as additional functionality in the HTML Forms module. The idea being a generic means for entering either many encounters for one patient, or one encounter for many patients, through a quick, register-like interface - (Mike 16:31, 16 March 2009 (EDT))
• Re-vitalize the specimentracking module to provide a means for tracking a lab specimen and the associated lab results across the various locations that may be involved, from the facility drawing the sample, to one that is involved in tranporting it, to one that is performing tests on it, etc. A specific use-case for this module will enable support for the PCR-test-tracking that PIH Haiti needs to implement. - (Mike 16:31, 16 March 2009 (EDT))
• Change objects to use a central history/audit table instead of creator/changedBy/dateCreated spread throughout all tables. See http://openmrs.org/wiki/Talk:Data_Synchronization_Project for a possible picture of what the table structure could be
• Changing popup ajax search boxes to jquery in-line searches -Ben 09:11, 27 January 2010 (EST)
• Rewrite Relationship Portlet Project
• Statistics module (as proposed by Carl on impl list) -Ben 14:06, 29 January 2010 (EST)
• hl7 output (or tight integration of mirth) -Ben 06:25, 10 March 2010 (EST)

Partially Described Projects

Improve "Restrict by Role" module

Mentor(s):	Darius Jazayeri
Assigned to:	?

Abstract: The Restrict by Role module allows you to limit certain users to only see a subset of the patients in the system. It has two downsides:

1. It does an expensive computation every time a restricted user tries to view or search for patients
2. It may not run on the latest version of the code

The point of this project is to fix those limitations.

Target: Goals:

• Ensure the module runs correctly on OpenMRS 1.4
• Upgrade the module to work with newer features in the not-yet-released 1.5 (i.e. use CohortDefinition instead of PatientSearch)
• Add caching of searches so that expensive queries are done less frequently.

---

Data Synchronization: Adaptive Data Transfer Algorithm

Mentor(s):	Maros Cunderlik
Assigned to:	?

Abstract: Data synchronization is a new OpenMRS feature allowing synchronization of data amongst a set of loosely networked servers. Such ability to exchange data is essential for operation of EMR system in rural areas where connectivity amongst sites maybe unreliable yet the need for timely centralized collection and analysis of data from remote sites exists.

As observed during the initial deployments in some areas, the transfer rates of data and data corruption issues over unreliable connections can vary widely. It is not uncommon for connectivity in remote sites to be in a state where 'it works but one cannot transfer any data'; i.e. basic protocols work but attempts at data transfer of any significant size (i.e. > 50KB) fail. This presents a unique challenge to data synchronization: how do we maximize transfer rates over networks with widely varying characteristics without undue burden of manual administration setup and monitoring? The goal for this project is to develop adaptive algorithm where the synchronization would adapt to the quality of the underlying network connection and automatically adjust frequency and size of data transfer packages with notifying administrators only in cases of prolonged or complete outage.

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

---