Having age and gender specific ranges in OpenMRS

Development
6

While FHIR does support many-to-one ranges per observation, most labs will report a single reference range (the “normal” range) ± additional text with the result. Labs don’t typically report critical or absolute ranges with the results.

This leads to something I left out: the interpretation (aka abnormal flag):

  • add interpretation column to the obs table. This would either store the codes in HL7 Table 0078 or be a FK to concept (FK may be overkill).

Since the determination of the abnormal flag and appropriate reference range is the responsibility of the party generating the result, any application generating lab results (including Bahmni) would be responsible for deciding if the lab being reported should be flagged as abnormal or include a reference range. We would continue to have canonical reference ranges (normal, critical, and absolute) in the concept dictionary.

Every numeric obs could include an abnormal flag and a normal range ± any range-specific information. In most cases, this is a single normal range (low & high) and, for abnormal results, an abnormal flag. Some labs include canned text like:

Normal <0.05 ng/mL Intermediate Risk 0.05-0.09 ng/mL High Risk >=0.10 ng/mL 95% Sensitivity and Specificity for MI: >0.6 ng/mL

or

Cholesterol Interpretation: Desirable: Adult <200 mg/dL Desirable: Child <170 mg/dL Borderline/Mod Cardiac Risk: 200-239 mg/dL High Cardiac Risk, Adult >240 mg/dL High Cardiac Risk, Child: >200 mg/dL

The reasons for this approach:

  • This is how everyone else is handling ranges (i.e., it’s up to the system reporting the result to report abnormal flag and reference range)
  • When you inevitably start needing to accept results from other systems, you can still properly report abnormal flags and reference ranges.
  • Lab machines often report results with abnormal flag and reference range.
  • Reference ranges can vary by machine used and vary over time, so trying to manage them in the dictionary can get even uglier than managing at the point of result generation.

While we could approach these as extensions of concepts, I think it helps to take this approach:

  • A concept reference range is a canonical reference range – i.e., absolute ranges ± normal or critical ranges independent of context or method.

  • Context-specific reference ranges belong not to the concept, but to the filler – i.e., the system or tool generating the result.

So, while storing context-specific reference ranges metadata alongside our concepts may help provide a central source for various data input methods to use, the important thing is that the data entry tools can get to these metadata (not that they’re part of the dictionary).