Uploaded image for project: 'HTML Form Entry Module'
  1. HTML Form Entry Module
  2. HTML-149

Add a New Tag to support creating Relationships via HTML forms



    • Type: New Feature
    • Status: Closed
    • Priority: Should
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: HTML Form Entry 1.8.0
    • Labels:
    • Complexity:


      We currently have 2 use cases that require a Relationship tag to be added to the HTML Form Entry module.

      1) For the PMTCT(prevention mother to child transmission) program for all infants we want to ensure a Mother relationship is created (as a lot of the reporting will run against this relationship). Given that the Mother is also a parent, we want the tag to take in multiple relationships, so the mother to child and parent to child are both created for the selected mother.

      2) For Community Health Workers (person not patient records) we want to restrict the allowable people that can be selected to persons that have a given person_attribute. Given we only want to be able to select from Community Health Workers that work out of the same health center as the patient, we want to have the ability to match the person_attribute to values pulled dynamically from the patient.

      To meet these 2 use cases the current proposed design for the Relationship tag is

      So the tag format will look like this
      <relationship type="21,34" whoAmI="A,A" required="true"
      replaceCurrent="false,true" personAttributes="Health
      Center:${currentPatientAttribute("Health Center")" personPrograms="3"

      type- this is the relationship_type_id (or UUID) for the relationships
      that should be created for the selected person. This attribute takes
      in a comma seperated list (as in the case of the PMTCT forms we want
      to create both a mother and a parent relationship).

      whoAmI - this is the side of the relationship, the patient the form is
      being filled out for is on (ie for a Mother to Child relationship, if
      the form is filled out for the infant then this should be set to B).
      This once again takes in a comma seperated list and the number of
      arguments should match the number of arguments in the type attribute.

      required - this is used for validation, and if true the form will not
      be able to be submitted without the required relationships existing
      for the patient. The code checks to see if the patient already has
      relationships existing, so validation will not fail if the
      relationships were set up prior to entering the form (in this
      situation the data entry clerk can edit or add new relationships or
      just ignore the question). The relatioship widget displays to the user
      all existing relationships (for the types we care about in the tag),
      so the data entry clerk should be able to decide if entry on this
      question is needed.

      replaceCurrent - this attribute determines if new relationships should
      be added to existing relationships or should replace the existing
      relationships (for example with the PMTCT stuff, we would want to
      replace the mother to child relationship, but add to the parent to
      child relationship - as the existing relationship may be the dad). So
      this is a comma seperated list as well.

      personAttributes - this is an optional field to restrict the search
      results based on person_attributes. This attribute takes in a comma
      seperated list of attributes. Each attribute can be entered as a name
      value pair (seperated by a , for example Health Center:Rwinkwavu
      Health Center. Alternatively the attribute value can be entered in the
      format of ${currentPatientAttribute("Health Center"), in this case
      the relationship tag will retrieve the value of Health Center
      attribute for the patient of the form and use this value as the value
      to match. I am not doing anything flash here, so it is just simple
      string matching that will only work for the relationship tag (so will
      probably want to change this out, if/when we have a more generic way
      to do this across the entire module). The value for the attribute is
      optional, and if left out then the search will return any people that
      possess the specified person_attribute.

      personPrograms - this is another optional parameter that allows the
      search results to be filtered based on program enrollment. So this
      takes in a comma seperated list of the program ids (or UUIDs). This
      can be used in conjunction with the personAttributes if necessary.

      display - this is a required value (however we could set a default in
      code to make this optional) and can have the value of 'search' or
      'dropdown'. This attribute determines which widget is displayed to the
      user to pick the person. Search will present the user with a popup
      search box, allow them to enter a search term then select from the
      returned list, all searches in the tag search based on person not
      patient, however you can search on patient identifiers and it will
      work. Dropdown presents the people in a simple drop down. I figured
      for specific searches like the CHW of a given health center that this
      list is likely to be fairly short, hence a search screen is not the
      most friendly option and a dropdown list would be preferrable. If the
      dropdown list is used when a large number of people are returned then
      this slows down the loading of the form (should really only be used
      for a short list, or we need to speed up the loading).

      Potential Enhancements
      Give the user the ability to edit existing relationships
      Give the user the ability to create new patients from the search box
      (if the related person is not found).


        1. DivPatch.txt
          0.6 kB
        2. form_html_source_omod_files.zip
          415 kB
        3. HTML149.txt
          60 kB
        4. htmlformentry-
          479 kB
        5. htmlformentry-
          479 kB
        6. screenshot-1.jpg
          148 kB



            lara.kellett Lara Kellett
            lara.kellett Lara Kellett
            0 Vote for this issue
            5 Start watching this issue