Design meeting 2015-06-01 summary: Condition lists + Encounter diagnoses

@Bahmni and @PIH folks take note (and others too, of course):

Today we discussed Condition Lists, and how those relate to Encounter Diagnoses, and how to approach Ruled Out.

Detailed notes here, if you can follow them: and we also started recording the audio halfway through.

To summarize, though:

Condition list

  • Bahmni devs introduced an API and top-level domain object around Condition List in the emrapi module recently.
  • We will want to move these to openmrs-core when the API is stable (and has been tested by using it in a UI, and via REST)
  • We want to introduce a condition status of REFUTED (this is FHIR’s term) for the case where you record a presumed condition, and later it is ruled out. (Currently you can only void it, or give it an end date, and neither of these capture the real meaning.)
  • You should not be allowed to save a new condition whose status is REFUTED (i.e. it’s only for the case where you already saved a condition, and later it is ruled out, but we prevent as best we can someone trying to misuse the condition list to store “not tuberculosis”

Encounter Diagnoses

  • Mirebalais devs implemented Encounter Diagnoses in the emrapi module long ago, storing these as obs groups.
  • We want to move these a domain object in openmrs-core, e.g. Encounter would have a List.
  • Burke would prefer to have an integer “sequence number” rather than the current “diagnosis order” that can be primary/secondary (and intentionally supports multiple primary diagnoses)
  • Since PIH has been using the current implementation for years, and based this on the CIEL:159946 concept, I think the bar should be high for making this change. (@PIH it would be helpful to know if “multiple primary diagnoses” is actually a feature people want.)

Links between Condition List and Encounter Diagnoses

  • The UI should make it easy to pick an existing condition off the condition list and say that it’s one of today’s encounter diagnosis. This linkage should then be stored in the database, e.g. as an (optional) FK to the condition table, from the to-be-added encounter_diagnosis table.
  • The UI should make it easy to add today’s encounter diagnosis to the condition list. This doesn’t require any changes to the underlying data model, but the encounter and encountertransaction web services need to support it.

(None of these tasks are ticketed or assigned to anyone yet. The idea was to get on the same page about design before we discuss the business side of condition lists with a Bahmni BA soon.)

Thanks for the summary. At a high level, this makes sense to me, and I agree that the bar should be high for changing primary/secondary diagnoses.

Adding @ddesimone to see if he has any thoughts re: multiple primary diagnoses.

@gsluthra, what would be the timeline for the condition lists?

@mksd is this of any help?

@mksd, we haven’t yet scheduled specific timelines for the features in the Bahmni 2017 roadmap. You’ll hear when we do though!

Thanks both. But how does this EA-40 relate to the Bahmni Trello card?

EA-40 covers work that the Bahmni team did around 2015, that never made it into the Bahmni product. The code and APIs are still around (I assume in the emrapi module).

When we pick up working on condition lists again we’ll be doing some of the analysis anew. (Though I assume it will take us in the same direction, and we’ll pick up this same code.)

Yes i believe that most of the work that the Bahmni team did is here