The Form Entry module is one of main data entry for OpenMRS along with HTML Form Entry and Xforms.

Form Entry allows end user managers to design a form's content and look and then allows for end users to fill out the form and submit it to OpenMRS.

If using the formentry module 5.x and below with the Sync Module you must take care with how the concepts are developed. Formentry still depends on internal concept.concept_id values being the same on all servers. The sync module cannot guarantee that to be the case. So all concept/form development must happen on one and only one server in your sync network. This is also the case with Metadata Sharing Module. Work is underway to fix these problems.

It is strongly recommended that you don't depend on sync to propagate changes to your infopath forms. PIH never did this successfully in Rwinkwavu, and this is one of the reasons that they transitioned completely to htmlforms.

One problem is that infopath XSNs are .cab files that contain a whole bunch of files inside of them. Some of these files have the hard-coded paths of the server that you were working on when you modified the form. The problem is that these hard-coded strings then get propagated to the other servers through sync (when its working). In the past in Rwinkwavu, PIH ended up with forms from one site being submitted to another site, which caused all kinds of problems.

Block org.openmrs.module.formentry at the parent sending level, and do all XSN manipulation by hand on each server. In the long run, this is still easier.

Other Resources

Example Usage



Release Notes

New line of releases for all OpenMRS 1.8+ versions

New line of releases for all OpenMRS 1.6+ versions

New line of releases for all OpenMRS 1.5+ versions



Ben Wolfe, Burke Mamlin