@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: https://notes.openmrs.org/Design-Forum-2015-06-01 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.)