Page Comparison

We are dealing with OpenMRS Concepts for various purposes by different types of users.
- Diagnoses: search and specify during consultation
- Tests: (Radiology/Lab) search and specify during consultation
- Drugs: search and specify treatment
- Notes by doctors/nurses
- Obs: as observations. e.g. Vitals recording by nurse, nurse/doctor noting down complaints/symtoms, screens noting down preliminary observations, intake/outtake etc.

The storage of such observations are done as below.
- Drugs/tests as Orders (Order table), results as observations (Obs table) tied to orders
- Others are stored as observations within encounters - diagnoses, vitals, any other notes, intake/outtake etc. 

This document specifically discusses setup/display/behavior/storage of observations that should be recorded through a "Concept-set-UI"

...

•  BP (is set = true, Class = Finding or Symptom/Finding, Datatype = N/A, with set members below)
  •   Systolic (Class = Finding, Datatype = Numeric, Absolute High = 160, Normal High = 120, Absolute low = 90)
  •   Diastolic (Class = Finding, Datatype = Numeric, Absolute High = 110, Normal High = 120, Absolute low = 70)
•  Temperature  (Class = Finding, Datatype = Numeric)
•  Last Visit (Class = Misc, Datatype = Date)

The above concept-set (VITALS_CONCEPT) can be used in Bahmni Apps to records vitals for a patient.
Usually, through configuration. For example in clinical->consultation the vitals tab can be configured as an extension

...

While rendering the UI, we need to read and interpret the schema defined above. In addition to this, we also need the UI to be capable of doing the following UI level interactions.
* Input kind - numeric, text, date time, single select, multi select, checkbox
* Validation - default, supported only for numeric datatypes in OpenMRS. Overridable or not?
* Display - group by sections, group by observation, display description and how
* required - whether mandatory or not

To configure all the above, we will have definitions associated with concepts that will govern the display and behavior in "Concept-set" UIs.
For each concept to be rendered on UI, we will have an associated configuration. All such configurations will be in a single file.

{
    "Symptoms" : {
        "autocomplete": true,
        "multiselect": {
           "type" : grid
        },
        "abnormalIndicator": true
        "validator": null
    },
    "Temperature": {},
    "BP" : {

       "required":true,
        "validator": {
            "validate": function(context) {
                //implementation specific
                //if context.patient.age > 18 and context.patient.gender = 'F', return [false, "blood pressure too high"]
            }
        }
    },
    "Chief Complaints" : {
        "dropdown": true
      },

 "defaults" : {
      "Number of living children" : 1,
      "Accepted Family Planning methods": ["Condoms", "Pills"],
      "Pain management given": true,
      "Safe Abortion, Remarks": "Remarks",
      "Malaria, Death Date": "2015-12-01"
   }

}

NOTE: "abnormalIndicator" is under discussion and maybe changed if we decide to move it as part of schema definition (OpenMRS concept definition).

...

"defaults" section contains the default values that concept can contain in the form. Key must be concept full name and value is the default value for each concept.

Persistence:

All observations are stored against an encounter by a provider. For observations coming out of a Concept-set interface, there would be several observation groups created depending on how a concept-set is defined in OpenMRS.

...

"config": {
		"conceptSetUI" : {
					"Tuberculosis, Next Followup Visit": {
    					"allowFutureDates": true
						},
					"Datetime" : {
						"allowFutureDates": false
						}
				}

}

...

Ability to Disable the Notes  for particular concept in Observation Form

...

"config": {
		"conceptSetUI" : {
			
				"Visual acuity, left eye" : {
						   "disableAddNotes": true
						}
		}
}

disableAddNotes