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?).
Mark
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.)
1 Like
We discussed this today, and updated the ticket: [TRUNK-5015] - OpenMRS Issues. 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.)
But I want to verify with people like @burke, @mogoodrich, and @jteich whether we’re all set to go.
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.
1 Like
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?
Andy
@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.
Ellen
We’re proposing that (a) it’s a manual process to add things to the condition list (b) we provide a shortcut to say “also add this diagnosis to the condition list.”
The magic I was talking about is that sometimes detailed concept mappings can help us understand the relationships between concepts. (E.g. in CIEL “Stroke (111103) is Same As SNOMED-CT 230690007” and “Personal History of Stroke (152512) has Associated Finding SNOMED-NP 230690007”, i.e. the same SNOMED concept.) In other word, “magic” that requires lots of concept mappings.
In practice I bet you would want to have an HTML Form Entry tag that does ensure that something is on the condition list. (E.g. an Epilepsy intake form would say <ensureCondition conceptId="PIH:EPILEPSY CONDITION">
The scope of this discussion is actually just the API for now.
It’s informed by our theoretical ideas of what the subsequent UI(s) would look like (and knowing what Bahmni built already). But people need to actually design/plan/resource/build UIs on top of this, and I hope HFE gets included.
Perhaps it’s a matter of perspective – i.e., whether you are seeing patients for chronic or acute care. From my perspective as a primary care physician, I see people all the time in my clinic for their chronic conditions and so my encounter diagnoses often contain a half dozen or more items from their problem list.
The intent of the diagnosis.condition property is to allow us to make an explicit connection when we can. That is, if you are seeing a patient for their “Type 2 Diabetes” today and you take the shortcut telling us to add that existing condition to the encounter’s diagnosis list, instead of simply adding a “Type 2 Diabetes” diagnosis to the encounter and leaving the relationship up to inference, we can add “Type 2 Diabetes” along with a link to the condition from which it came. Likewise, if you are seeing the patient the first time for “Hypertension” and you ask us to add it to their condition list, we can record that instead of leaving it up to inference.
At this point, we are working with OpenMRS concepts, so recording diagnoses for the encounter at the clinical level. When we need to record billing codes (ICD or CPT), they would need to be added as additional properties of the diagnosis. I don’t think we’re anywhere near the position to be able to manage separate terminologies for encounter diagnoses, problem/condition lists, and past medical history items (and the inherent relationships & mappings between them). At this point, we simply want to be able to record clinical diagnoses (as concepts) associated with the encounter.
I don’t think it is just about attaching billing codes, but understanding that there are different levels of granularity required at different stages of documentation and in different segments of the EHR. There is an interesting discussion started on HIS talk (histalk2.com) about managing problems. I think there can be flags on concepts which filter which appear in which section of the EHR, but the key is understanding how problems change over time and that the “assessment” or “encounter diagnosis” can be different from the problem list entry. I understand we might not fully implement this functionality in OMRS, but I would not want to architect to an inferior model.
@akanter I think that this won’t affect what we’re discussing now.
We’re saying that in the API and data model:
- encounter diagnoses point to a concept +/- concept name +/- free-text
- we do not constrain to only specific concepts/classes
- condition list items point to a concept +/- concept name +/- free-text
- we do not constrain to only specific concepts/classes
- an encounter diagnosis may optionally point to a condition list item
- the concepts for the diagnosis and the condition don’t have to be the same
FYI I marked this ticket Ready For Work.
(I also made a last-minute change in the name of the new domain object from Diagnosis to EncounterDiagnosis as this seems clearer.)