Hi,
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?
Basically, I want to understand the technical difference btwn the two.
If one wants to make an sql query that on selects Diagnoses from the Obs Table, how could it actually look like. I know this is a very basic question but I wanna learn this Concept.
I haven’t worked with Diagnoses in emrapi module, may be someone from the Bahmini team can explain.
If diagnoses are stored as Obs we need to know what differentiates them from regular Observations.
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.
Others?
I think the approach may vary from implementation to implementation. For example, looking at coded concepts for “diagnosis” in OCL, you can find PROBLEM ADDED, Newly diagnosed disease, and PROBLEM LIST, any of which might be used to record a diagnosis during an encounter. I’d expect the pattern to be consistent at any given implementation, but different implementations may have taken different approaches.
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.
Are you saying migration is impossible?
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:
Thats true.
I had a hint on this. However, I just wanted to learn the technical bit of it 
Samuel
@samuel34 the short answer is that in the reference application, diagnoses are represented with this construct: https://openconceptlab.org/orgs/CIEL/sources/CIEL/concepts/159947/
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.)
Thanks, I’m now left at a point of understanding how this works 