Patient Conditions and Encounters

Tags: #<Tag:0x00007fa3fb0d71a8> #<Tag:0x00007fa3fb0d70e0> #<Tag:0x00007fa3fb0d6ff0>

Hi all,

OpenMRS is Encounter centric in the sense that almost all patient data is associated with an encounter.

The Condition is a relatively new domain to core. It as FHIR Resource, it can be associated with an encounter(checkout the Compartments section).


Question

Does it make sense to have Conditions linked to an Encounter in our data model?

Why I believe this is required?

At Mekom, we are consuming the <condition/> HFE tag in a couple of forms, this tag is used for capturing Conditions of a patient. While in ‘view’ mode(of the form), we require to view conditions recorded for that particular encounter.

What are your thoughts on this?

/ cc: @mksd, @dkayiwa, @ibacher, @mogoodrich

As long as the encounter is optional, am happy adding it to conditions. :slight_smile:

1 Like

Yeah sure, the encounter should be nullable making this backwards compatible.

If I go into ‘edit’ mode, what should I be expecting to see?

We also expect to see existing conditions recorded in the past encounter that we are editing.

@dkayiwa assuming we do this, will it be possible to backport it to 2.3.x? Because we will need this soon and I don’t think we can go through the release of 2.4.0.

We generally back port bug fixes instead of new features. But we have once in a while broken this rule to address a real practical need. Basing on the circumstances that you are in, and the fact that it is small change, i would say YES to back porting it to platform 2.3.x

1 Like

Thanks! That’s quite a relief! Thanks for being flexible.

@samuel34 can you please create a ticket in TRUNK?

Opened ticket at:

2 Likes

Certainly no reason to prohibit conditions from being tied to encounters – with some notes:

There have been numerous discussions on Condition Lists (search for it in Talk) and the difference between them and Encounter Diagnoses. The link below is one to consider. The upshot is that if you want to say what health issue was the focus of an encounter, that’s the diagnosis. It you want to say what health issues a patient has – generally long-term – those are conditions. They interplay in a manner described in the link.

That said, a clinician could reasonably choose to mark a particular condition as something that was relevant to a particular encounter (PS I’ve built this very feature several times in other systems, and few if any clinicians have ever used it). As long as it’s optional, there’s nothing semantically or clinically wrong with offering the linkage.

3 Likes

Code committed at: https://github.com/openmrs/openmrs-core/commit/53e4d9ce7b94b4c6e7cb0f7b817244664d3c0124 and https://github.com/openmrs/openmrs-core/commit/a3cbb000e944f9d56cb716e38d74477269ddaeff

Back ported to branch 2.3.x at : https://github.com/openmrs/openmrs-core/commit/94de95eff2e182acb255a86af9b7d113e4b0e717

Thanks @dkayiwa

1 Like

I agree with you.

While I have no opposition to the change here, I just want to note for posterity that the boundaries between a FHIR Condition and an OpenMRS Condition are different. In particular, a FHIR Condition is exactly the resource to use to express an encounter diagnosis as well as an on-going problem. While, like @jteich, I don’t think there’s a good semantic reason not to store the encounter in which the condition occurred, we do have to navigate the difficulty of having diagnoses stored as Obs and problems stored as conditions. FHIR differentiates these two uses of Condition via the Condition.category field.

E.g., to build current problem list for a patient, one might use this query in FHIR:

/Condition?category=problem-list-item&clinical-status=active&verification-status=confirmed

Meanwhile, to find the diagnoses associated with a particular encounter, one might do this:

/Condition?category=encounter-diagnosis&encounter=27

My point in posting this is just to document some of the inherent difficulties in mapping between FHIR resources and OpenMRS objects.

1 Like