Page Comparison

Background

Most of the data collected by OpenMRS is stored as patient-specific observations (e.g., weight, pulse, serum potassium level, their answer to "How many children live in your home?", etc.).  OpenMRS has a finite list of data types for observables:

...

Example: the saveObs(obs) method of PatientHandler will look as follows,

@Override

      public Obs saveObs(Obs obs) throws APIException {

            Object data = obs.getComplexData().getData();

            //No File I/O operations necessary for this handler

            // Set the required value to be stored in the database column

            obs.setValueComplex(data.toString());

            // Remove the ComlexData from the Obs

            obs.setComplexData(null);

            return obs;

      }

A value similar to PatientHandler|PatientId:1 will initially be stored in the database.

...

A minor complication here is that the custom <openmrs_tag:conceptField> used to retrieve concepts does not downcast concepts to ConceptComplex. This means a concept is only aware of its data type, such as (in the case of a complex concept)

tmpConcept.hl7Abbreviation = ‘ED’

Thus the concept is not aware of what its handler value is.

This led to problems, since I do not wish to alter the existing and widely used <openmrs_tag:conceptField> tag class to meet my requirements. Also given that casting would not achieve my desired result, I decided on the following method,

In the JavaScript of the ObsForm.jsp page,

else if (datatype == 'ED') {

                        DWRConceptService.getConceptComplex(tmpConcept.conceptId,checkHandler);

{color:#3366ff}}

As you can see, if datatype == 'ED', I call the DWRConceptService to retrieve a ConceptComplex object, access its handler string and use that to decide on which option to select.

...

                              ii.      Consider possibility to create a custom tag class which supports all domain objects, in order to carry out the above step more efficiently.

Timeline

...