Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Create a New Person Attribute Type

  • Go to Administration screen
  • Click Manage Person Attributes Types
  • Click Add New Person Attribute
  • Field definitions:
    • Name: Any string you want to recognize this type by. Spaces should not be used
    • Format: Most likely it will be java.lang.String. Other possibilities are org.openmrs.User, org.openmrs.Concept, and org.openmrs.util.AttributableDate (version 1.4)
    • Foreign Key: The only time a foreign key value is needed is when you are using a separate table for the answers. A good example of this is the Civil Status attribute that links to the concept civil status for its possible answers, see here on how to implement it More information about coded concepts is available elsewhere on the wiki.  
    • Searchable: Whether or not this attribute is included in searches
    • Description: Text blob describing this type
    • Edit privilege:The privilege needed by user to edit this person attribute.

Listing and Viewing of Person Attribute Types

Person attributes can be included in search screens and edit screens. Separate attributes by commas.

  • "Listing" refers to a search listing after someone types a few characters into a search box.
  • "Viewing" refers to the display and edit pages of a patient/user. Attributes to be shown on the patient dashboard and short patient edit screens. Note: All attributes are shown on administration patient and user edit screens.
  • Once you add attributes here, they will show up headed like PersonAttributeType.NameOfAttributeType.

To get a display name for this you need to add an entry to your custom messages file like so (without the <>'s):PersonAttributeType.<attribute name>=Attribute Name

  • If the attribute name has a space in it, it should be removed or replaced with a \ in the custom name like so: PersonAttributeType.<attributename>=Attribute Name
    PersonAttributeType.<attribute\name>=Attribute Name
  • See how to set custom.messages files on the runtime properties wiki page: Overriding OpenMRS Default Properties
  • The order of Person Attributes can be changed as of OpenMRS 1.6. To change the order the attributes are displayed in, click the box next to the Person Attribute name, and click the "Move Up" or "Move Down" button below the list.

Using Person Attribute Types on Forms

  • Create a field of type "database element". Set the `table` to be "person_attribute" and the `attribute` to be "value".
  • If you want them to then appear with data in the forms, you need to be able to define a default value.
    • Person attribute data is entered on the Edit patient pages. Attributes are viewed in InfoPath by setting the field's `Default Value` to: ${patient.attributeMap.Cell} where "Cell" is the attribute type name.

...

    • person

...

  • Create a person attribute, per usual steps
    • Format:  org.openmrs.Concept (indicates this value is being linked to a concept from the dictionary)
    • Foreign Key: enter the concept_id for the concept from which you would like to use the coded responses
    • As mentioned earlier, a good example of this is the Civil Status attribute, which links to the "civil status" concept for its possible coded answers (married, single, divorced, etc.). 

Image Removed

Create a New Person Attribute Type

  • Go to Administration screen
  • Click Manage Person Attributes Types
  • Click Add New Person Attribute
  • Field definitions:
    • Name: Any string you want to recognize this type by. Spaces should not be used
    • Format: Most likely it will be java.lang.String. Other possibilities are org.openmrs.User, org.openmrs.Concept, and org.openmrs.util.AttributableDate (version 1.4)
    • Foreign Key: The only time a foreign key value is needed is when you are using a separate table for the answers. A good example of this is the Civil Status attribute that links to the concept civil status for its possible answers, see here on how to implement it.  More information about coded concepts is available elsewhere on the wiki.  
    • Searchable: Whether or not this attribute is included in searches
    • Description: Text blob describing this type

Listing and Viewing of Person Attribute Types

Person attributes can be included in search screens and edit screens. Separate attributes by commas.

...

  • If the attribute name has a space in it, it should be removed or replaced with a \ in the custom name like so: PersonAttributeType.<attributename>=Attribute Name
    PersonAttributeType.<attribute\name>=Attribute Name
  • See how to set custom.messages files on the runtime properties wiki page: Overriding OpenMRS Default Properties
  • The order of Person Attributes can be changed as of OpenMRS 1.6. To change the order the attributes are displayed in, click the box next to the Person Attribute name, and click the "Move Up" or "Move Down" button below the list.

Using Person Attribute Types on Forms

  • Create a field of type "database element". Set the `table` to be "person_attribute" and the `attribute` to be "value".
  • If you want them to then appear with data in the forms, you need to be able to define a default value.
    • Person attribute data is entered on the Edit patient pages. Attributes are viewed in InfoPath by setting the field's `Default Value` to: ${patient.attributeMap.Cell} where "Cell" is the attribute type name.

Anchor
coded person attribute
coded person attribute
Creating Coded Person Attributes

  • Create a person attribute, per usual steps
    • Format:  org.openmrs.Concept (indicates this value is being linked to a concept from the dictionary)
    • Foreign Key: enter the concept_id for the concept from which you would like to use the coded responses
    • As mentioned earlier, a good example of this is the Civil Status attribute, which links to the "civil status" concept for its possible coded answers (married, single, divorced, etc.). 

...