Incorporating Encounter Diagnoses into openmrs-core

Development
1

PIH first introduce “Diagnoses” in the emrapi module for their Mirebalais project (storing the actual data in an obs group). This has been included in the Reference Application and in Bahmni for years without any real changes being requested to the use case, so I’m pretty confident that we’ve got this right, and it’s time to implement Encounter Diagnoses in openmrs-core.

The general idea would be to add an encounter_diagnosis table (and to deprecate what is being done in emrapi).

FYI @burke, @jteich, @mogoodrich, @bharatak

@jthomas, I’d like to discuss on a design call.

2 Likes
2

@darius @burke @jteich @mogoodrich @bharatak we have an opening on Wednesday, January 25 and Monday, January 30th. I am guessing with this group that the Monday date works best but please correct me if I’m wrong.

3

I will be travelling the next two weeks so it’s unclear if I could make either of those times, but I don’t need to be there.

I don’t have a problem with it being moved over, however in the spirit of “if-it’s-not-broke-don’t-fix-it”, @darius do you have a compelling reason to prioritize this?

Take care, Mark

1 Like
4

I think it is better to move important & useful features to openmrs-core so that it is useful for larger community. emrapi does a lot of things, i think this is a better to make it leaner :slight_smile:

I prefer having the call on Monday if possible.

5

In our 2017 Bahmni roadmap we intend to work on Condition Lists, Care Plans, and also some FHIR work. We’d rather have these things work against openmrs-core code, rather than having yet more new functionality require the emrapi module.

There’s not a specific driver right now but I’m trying to get us ahead of things. :slight_smile:

6

Seems fair… I’m certainly not opposed to it, just wanted to play devil’s advocate given our limited resources.

Take care, Mark

7

Thanks @darius and @bharatak. I have similar concerns to @mogoodrich and would love to be a part of a design call where we can think through some of the implications of this change on the rest of the module and distribution ecosystem, and work to mitigate it. Personally I think this needs to be given equal or greater design consideration and forethought than the actual design of the encounter diagnoses feature.

@mogoodrich and I could probably join the call on Monday the 30th, but the Wednesday call would be more difficult.

Mike

8

Monday Jan. 30 works for me.

9

It looks like we failed to schedule this. @jthomas can we take another shot at scheduling?

Looks like Feb 6 and Feb 8 are both open (though it may be tight to schedule this for Monday on a Friday afternoon).

10

Looks like this is not being discussed on today’s call so would people prefer Wednesday (2/8) or Monday (2/13)?

@darius @jteich @mogoodrich @bharatak @burke

11

Either is fine for me.

If we are expecting @bharatak I think Wednesday is impossible. (I don’t know if he’s planning to join or not.)

12

I figured as much but wanted to leave the option out there. @bharatak let me know if you want to make it to this discussion and we will get this on a Monday call.

13

Monday 2/13 is good for me.

1 Like
14

I am going to put this topic down for Monday. @bharatak and @mogoodrich please let us know if you can not attend.

15

Please do it on Monday. I’ll catch up with @darius on what happened.

16

I will try to make it on Monday… I don’t know if it’s critical that I make it though, as long as there is a design summary to review?

Mark

17

I expect (hope?) there will not be much design discussion.

I think the big question is going to be what steps need to be taken to ensure an easy upgrade path. So it would be great if one of @mogoodrich and @mseaton could be there to represent their concerns on that front.

18

Yeah, sorry, that’s what I meant… the design behind the migration.

I will do my best to make the call… looks like I should be free.

Take care, Mark

19

We had a good design call discussion today (including myself, @jteich, @mogoodrich, @wyclif), discussing how we could incorporate Encounter Diagnoses into core.

We considered both the EMRAPI module and FHIR resources and came up with this plan:

1. Support for encounter diagnoses in core:

  • Migrate CodedOrFreeTextAnswer to Condition (will be used for condition lists and anywhere else we need conditions aka diagnosis/problem/health concern)
  • Migrate Diagnosis to EncounterDiagnosis, which extends Condition to add ordinality (PRIMARY vs. SECONDARY)
  • Add methods to get primary and secondary diagnoses to Encounter

2. Backwards compatibility

  • Refactor the EMRAPI module’s diagnoses as a façade using the new encounter diagnoses in core.

3. Going forward

  • Create a ticket to migrate data into core’s new encounter_diagnosis table
  • Update UIs to use new features from core

Here’s a side-by-side comparison:

image.jpg879×522 89.9 KB

Notes

  • Condition aligns us with FHIR’s Condition resource
  • CodedOrFreeTextAnswer is a generic solution to supporting coded or free text that adds another layer of abstraction in the API. We prefer to incorporate this functionality into Condition
  • Both @jteich and I preferred EncounterDiagnosis to simply Diagnosis (ambiguous) or Indication (FHIR’s term)
  • Some renaming:
    • Order is replaced with Ordinality for PRIMARY vs SECONDARY
    • Certainty becomes VerificationStatus supporting PROVISIONAL (previously PRESUMED) and CONFIRMED to align with FHIR
  • We eliminate the need for DiagnosisService once EncounterDiagnosis is a property of Encounter
  • Design call notes here

I’ve adjusted TRUNK-5015 accordingly.

20

FYI there’s currently an implementation of condition in the emrapi module, which I don’t know of anyone using in production now, and we’re making some tweaks to it for a Bahmni implementation now. Code is at: https://github.com/openmrs/openmrs-module-emrapi/blob/1.20/condition-list/src/main/java/org/openmrs/Condition.java

Things that I would expect in the OpenMRS condition model that aren’t in your diagram:

  • link to previousCondition (so we can track a history)
  • Date onsetDate
  • String additionalDetail
  • Date endDate
  • Concept endReason

I’m not in love with calling the new core class Condition without adding some extra fields (which might not be directly relevant to EncounterDiagnosis)…