How to add a new field on an existing form ?

Application Name: OpenMRS Standalone Version Number: 2.X

Question: I am new to the OpenMRS. Now I have a standalone version 2.X of OpenMRS and Ive been trying to add a new field to an existing form. For example I want to add “email” field to the patient registration page.

What are the list of things (add new label, duplicating new form, maybe there’s other places I need to configure as well) I need to do in order to simply add this one new field ?

Hi @abiieez,

I believe your question covers the registration form, which is a bit of a particular case and that is handled through the separate Registration App module (as opposed to medical encounter forms that are handled by the HTML Form Entry module).

The layout and content of the registration form is specified via a JSON app configuration file. This is an example of ours where we added a person attribute Father Occupation to the (new) Next of Kin section of the registration form:

  "type": "personAttribute",
  "label": "${project.parent.artifactId}.app.registerPatient.father.occupation",
  "formFieldName": "fatherOccupation",
  "uuid": "51c5e88c-7e13-11e5-8bcf-feff819cdc9f",
  "widget": {
      "providerName": "uicommons",
      "fragmentId": "field/text"

When thinking/designing the registration form, you can record data into (1) ad-hoc tables (that would the case of the address or the patient name…), (2) as person attributes (phone number, father occupation…) or as (3) obs.

The email address would typically be a person attribute and you will likely have to create a new person attribute type for it first, before referring to its uuid in your config snippet.

1 Like

Thanks for the information. Now I can see the email on the registration form.

Now I need to add a new label and legend for email as well, where should I put the following message codes ?

“legend”: “”

“label”: “”

Or I can’t add any new code and should use the text (“Email”) right way ?

In ./api/src/main/resources/, that’s for the default locale.

However, I wouldn’t prefix them with registrationapp. That is the Registration App module’s prefix for internationalization (I18N) of messages. I would use as a prefix the artifactId of your own custom module to avoid any potential collision.

That would “work”, but that would be bad practice since you would bypass the I18N process.