Like we all know, platform versions below 2.2 have been persisting Diagnosis data in the Obs table. For some usecase, we need to migrate the Diagnosises to their new Table. see https://issues.openmrs.org/browse/TRUNK-5342.
Well, I just wanna be sure of this, just to continue working confidently. How do we identify a Diagnosis from other Obs data. Are they grouped by some concept_set?
Across distributions I don’t think there is a single answer to this.
For instance those should be obs for which the underlying concept is of class Diagnosis (see here in ConceptClass and here in the wiki). But that particular way to setup the metadata is not always respected. For instance in Bahmni those diagnoses concepts are not always set that way (a mistake IMO) but do belong however to a well defined superset that regroups all diagnoses.
The approach we took early on with problem lists (aka condition lists) was to create PROBLEM ADDED and PROBLEM RESOLVED concepts. Creating an observation with either of these would indicate the addition (or removal) of the answer (symptom, finding, or diagnosis) from the problem list. Creating the problem list involved finding all problems added that had not subsequently been removed.
Note there’s a difference between
encounter diagnosis – a diagnosis being addressed within a clinical encounter
diagnosis in a condition list – providers typically keep a “condition list” (often called a “problem list”) that exists independent of any given encounter and represents a patient’s clinically relevant medical conditions, which may include symptoms (pt’s complaints), findings (what the provider observes), or diagnoses.
You can see why we are pushing toward explicit “encounter diagnosis” and “condition list” management out of the box to help standardize approaches.
Just to be clear, @samuel34 you are specifically asking how to identity Obs that are used to persist “EncounterDiagnoses” created by the EMR API module in order to implement the migration as specified in this ticket?
I would take a look at this and other “Diagnosis” classes in EMR-API to see how this works:
I.e. there would be an obs group with concept 159947, and it would contain either a coded diagnosis obs with concept 1284, or a non-coded diagnosis obs with concept 161602, as well as some other supporting obs for the certainty, order, etc.
From the perspective of emrapi module, those concept_ids are not hardcoded, but rather they are looked up using concept mappings as defined in the DiagnosisMetadata class that Mark shared. (You can see an example in the “org.openmrs.module.emrapi:Diagnosis Concept Set” mapping in the CIEL concept I linked to.)