Please do it on Monday. I’ll catch up with @darius on what happened.
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?
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.
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
We considered both the EMRAPI module and FHIR resources and came up with this plan:
Condition(will be used for condition lists and anywhere else we need conditions aka diagnosis/problem/health concern)
EncounterDiagnosis, which extends
Conditionto add ordinality (PRIMARY vs. SECONDARY)
- Add methods to get primary and secondary diagnoses to
- Refactor the EMRAPI module’s diagnoses as a façade using the new encounter diagnoses in core.
- Create a ticket to migrate data into core’s new
- Update UIs to use new features from core
Here’s a side-by-side comparison:
Conditionaligns us with FHIR’s Condition resource
CodedOrFreeTextAnsweris 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
- Both @jteich and I preferred
- Some renaming:
Orderis replaced with
Ordinalityfor PRIMARY vs SECONDARY
VerificationStatussupporting PROVISIONAL (previously PRESUMED) and CONFIRMED to align with FHIR
- We eliminate the need for
EncounterDiagnosisis a property of
- Design call notes here
I’ve adjusted TRUNK-5015 accordingly.
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)…
PS- as a side-note, I wonder if there’s any real value to having an extends relationship between the EncounterDiagnosis and Condition domain objects. (I think it’s more likely to get us into trouble at some future point vs saving us any actual effort.)
A fair point, @darius regarding having Condition extend EncounterDiagnosis. I don’t know if Burke literally meant for it to extend in the Java class sense of the word. I would think that an EncounterDiagnosis would just have a Condition property.
Also, do you remember if there was particulary reason for having the CodedOrFreeTextAnswer class? Was it just an idea as a way to do something more generic that never caught on. I do remember finding it kind of clunky, and in the refactoring we weren’t planning on using it.
Also, something I keep forgetting o ask–I assume the idea is that this new functionality will be in platform 2.0 (but not backported to the 1.x line?).
I created this during the Mirebalais project because the idea of having a single value that may be Concept, Concept+Name, or String seemed like a generic use case. (But yeah, this didn’t catch on elsewhere.)
I was hoping you all would discuss this on the design call.
I expect we’d implement this in the master branch of openmrs-core, so it would end up in Platform 2.1.
I was assuming that we should leave the API for dealing with diagnoses in the EMR API module exactly as it currently is, just its implementation would need to switch based on whether it’s using an older or newer version of openmrs-core. We can mark it as deprecated though, in favor of using the functionality in openmrs-core.
Also we need to define more concretely the migration path (since for existing implementations encounter diagnoses will currently be stored as obs). I guess the approach would be that the first time you start up the emrapi module on platform 2.1+ it should start migrating (in the background?), creating encounter diagnoses and voiding the existing obs. (Or, @mogoodrich, do you think the obs should be left in place?)
Reviving this old thread, because I think that this would be a great project for an Andela team to work on.
@burke, I would like us to try to get https://issues.openmrs.org/browse/TRUNK-5015 into a Ready For Work state in an upcoming design call, so it’s ready by Oct 1. (@jthomas, can you schedule this? I don’t think you need to poll for availability first, just put it in an open slot.)
Will schedule for Wednesday, September 20th
We discussed this today, and updated the ticket: https://issues.openmrs.org/browse/TRUNK-5015. And then I made a few more updates after looking at what is already implemented for conditions in the emrapi module, and Bahmni.
Personally I’m ready to mark this ticket Ready For Work, for one of the Andela teams to pick up. (And I assume that some more detailed design discussions will happen as they pick up the work, including about sequencing. E.g. I would do diagnoses first, and move Conditions to another ticket.)
Wyclif and I are proposing to introduce a new convenience class “CodedOrFreeText” that we should use going forwards wherever we’re asking the user to select a concept or free-text. (@mogoodrich, this is similar to the CodedOrFreeTextAnswer class in EMRAPI)
In Condition, we will require a clinicalStatus, which can be ACTIVE, INACTIVE, or HISTORY_OF. (This last one maps imperfectly to FHIR’s “remission” status, but this is an important convenience for a common OpenMRS use case where you don’t have a completely precoordinated concept dictionary, and it’s already implemented in the EMRAPI module, and used in Bahmni. This is what we ended up with at the conclusion of this very long talk thread about conditions in Bahmni.) FYI @burke.
@burke, Condition will also include optional
String additionalDetail and
Date onsetDate. Both of these are in EMRAPI and Bahmni. Both have an exact map to FHIR.
@burke what should our javadoc say about about Diagnosis.condition field? I wrote:
May refer to a new condition to be created as a result of this diagnosis, or an existing condition that this encounter is following up.
All looks very good, although I don’t know how clear/confusing the diagnosis.condition will be. There is probably a use case from previous discussions that I have forgotten; but otherwise I can’t think of how or why someone would tie an encounter diagnosis to a condition. We have said that you can (operationally) use the condition list to facilitate choosing a diagnosis for the current encounter, and that it would also be nice to facilitate easy copying of today’s diagnosis onto the condition list, but otherwise they don’t meet up very much.
Is it intended to allow a new diagnosis to somehow be associated with a different condition on the CL, sort of a new child in a class? The “refer to a new condition to be created” would simply be copying this diagnosis to the CL; if you really want to diagnosis someone with one diagnosis for the visit and put something else on the CL (say, today’s diagnosis is “diabetic ketoacidosis” but you want the CL to contain the more chronic “diabetes”), I don’t know that you need the linkage to validate that. If it’s “existing condition that this encounter is following up”, then that might be part of the encounter structure – reason for visit, as we discussed here a few months back – but not really part of the diagnosis.
The primary use case is to explicitly link diagnoses selected from the patient’s problem list to the encounter. So, for example, you could track encounters for a chronic problem without having to rely on inferences.
Yeah, I get that… I would say that’s an element of the encounter, not of any one diagnosis. The diagnoses might be “pneumonia” and “dehydration” and you might also want to associate the visit with an existing problem like “lymphoma” because it’s incidentally relevant to what you observed or did today, but lymphoma doesn’t necessarily belong to either diagnosis, and maybe not really to either one.
So, more accurately, encounter.associatedCondition
I think that’s right, but I won’t jump up and down for it.
The purpose of diagnosis.condition, just so that when the user explicitly drags an existing condition from the condition list onto today’s encounter diagnoses (or however exactly that works in the UI), we can explicitly record that this was done.
I think that encounter.associatedCondition would also be a nice thing to have. In fact this seems to follow more closely how it was implemented in Bahmni (i.e. there’s a “followup” button on each row in the condition list, as opposed to actually dragging something from the CL to the encounter diagnosis list).
@burke, I’d like to get this ticket Ready For Work in the next couple of days so that it can be picked up by Andela developers next week, so please do comment whether the ticket overall has any remaining flags, or it’s good to go.
Folks, there is a clear difference between encounter diagnoses, conditions/problem list items, and past medical history. They each have a specific function and coding/reporting requirements. Perhaps I am coming late to this discussion, but what am I missing? Copying from problem list to encounter diagnosis requires conversion to a concept with a fully-specified ICD code, for example in many settings. Copying from encounter diagnosis to problem list might involve changing the concept to one that does not include billing modifiers or is a more chronic condition. Past medical history might have a third, comprehensive history included but require ICD coding if moved to the active encounter diagnosis, etc.
Should we have another call about this that I can make?
@akanter we are designing the API that will support building a UI which lets a user take an active condition and use this as today’s encounter diagnosis, with a single click. And when this happens, you should be able to save a link from the diagnosis to the condition that it came from. Are you saying this should not be allowed as a workflow? (In fact Bahmni didn’t prioritize or build this one, but instead prioritized letting the user click on a condition in the condition list to say that this encounter is following up on that condition. And Jonathan also seems to be saying that’s the more important workflow.)
Or are you saying that the concept for “Hypertension (Diagnosis)” is not the same as the concept for “Hypertension (Condition)”. In that case, when the eventual UI is built, it could use some business logic based on mappings in the dictionary to convert from the condition concept to the diagnosis concept. But I don’t actually see this level of mappings, even in the CIEL dictionary. (I had found a stroke vs history of stroke example that I mentioned in this post: Conditions List for Bahmni, but I don’t see an equivalent for the malignant hypertension concept.)
Alternately, we could let the system be configured to not allow concepts to be chosen as encounter diagnoses if they don’t meet some criteria. (That seems independent of this discussion though.)
I was hoping to have this ticket ready-for-work by Monday, so a team of Andela developers can pick it up.
One possibility is to pull out this one thing, and make the rest of it ready for work. Then we can get do another call to look for consensus about whether we want diagnosis.condition and/or encounter.associatedCondition and/or to get episodes of care into the model (and make the ball of wax even bigger).
PIH has been doing more and more work with NCDs and that is when this really gets interesting (and useful). Hypertension, Epilepsy, Diabetes (type 1 and 2), Mental Health are main areas. Are you thinking that something magical will transition a particular diagnosis to a condition/problem list? Or these will these be managed completely separately?
I hope this discussion is not limited to one UI. It will be a happy day when we add conditions to htmlforms.