Expanding on Coded Value Sources in obs - Advanced Design Page

Design Discussion no 01:

Displaying matching obs value box based on the provided concept type.

Displaying matching obs value box based on the provided concept type.

1. Existing scenario:
   1. Assuming that the user navigated to the ObsForm.jsp and selected a complex Concept, the obs value field will display a link and a button allowing him to upload a complex object file.
   2. Change: need to provide alternate method if user selects a complex concept of domain class type.
      1. Solution: When the user selects a concept, it is sent to a JavaScript method which controls which data entry field (etc. numeric, Boolean, concept, complex etc.) is displayed to the user. However as the user received a concept object and not a complex concept object, he cannot pinpoint the specific handler type.

So, if the concept is complex, call a DWR service method which will identify the matching complex concept and retrieve the handler string. Now use this string to do an if else test and display a matching input option to enter proper data.

Question: what kind of obs value option should we display to users?

In the case of domain objects, users should be able to select the matching instance by typing into an auto complete box.  This could be provided easily using the fieldGen tag.

The drawback of this system would be that we would need to input n many <tr> into the jsp page, one for each type of domain object supported by the system. 

An alternative approach would be to code a new set of fieldGen tags, which could be configured to identify the specific domain object types based on the concept passed in.

Design issues for the future

 

Storing specific criteria to identify domain data objects ‘allowed’ for the given concept.

 

To explain, assuming that I create a concept named RETIRED_PATIENT, then only retired patient instances can be assigned to it.

To support this functionality, we would need to store additional data along with the complexconcept object.

So maybe we are looking at an extra table to store such data, or else we're planning to accommodate it in the existing concept_complex table?

PS: these data need to be stored with the concept, and not with the obs.



An earlier (and rejected by myself) scenario , but included here for further reference....

 an alternative (and preferred) method, 

Can domain Objet handlers be truly independent of other code ?

No, for the following  reasons,

We need to customize the jsp views that allow users to select proper value inputs

(Example: Need to provide an auto complete box to search for matching patient objects to input as value for PATIENT_CONCEPT)

Therefore, if we go ahead with the auto complete option for ‘value’ entry (which  is the favored method) we will need to ensure that each domain object handler class is supported by the fieldGen tag.

This should not be an issue, since this tag already supports all of the important domain classes.

In the case that the fieldGen tag does not support a new domain object handler, we would have to provide a default input option such as a text box etc.

However I am unable to come up with a way to provide such customization code in the handler class itself.

Domain classes currently supported by the fieldGen tags are

• Location
• Patient
• OrderType
• Concept
• Encounter
• User
• Drug