At the PIH primary care clinics in Mexico, they need to save an additional piece of data with each diagnosis – whether the MoH would consider it a “first time” diagnosis or not, based on the criteria the doctors know. At the same time, “Confirmed” is not a meaningful piece of information about a diagnosis, because at the primary care clinic they don’t have the labs etc needed to really “confirm” things.
In the form, we’re using <encounterDiagnosesByObs>. It’s been requested that the “Confirmed” checkbox be replaced with a “First time” checkbox.
Does anyone have good ideas for how to go about doing that?
I would be against storing the “first time” information in that for “Confirmed” because it looks like a hack.
Our convention for extending the core model in regards to things that are not generally needed else where, has been through attributes. Examples are, person attributes, visit attributes, location attributes, etc.
Therefore i would propose something like diagnosis attributes.
@dkayiwa@bistenes … I agree that attributes seems like the “right” solution to do this…
Unfortunately, @bistenes there are a a few complications to this if we use our current model… we’d need to expand the EncounerDiagnoses HFE widget to support this (optional) attribute.
More unfortunately, we currently are using the “old” obs model for diagnoses at PIH, so we’d want to either 1) migrate to the new model first, or 2) update both the old and new versions of the widget to support this.
Preference would be to do 1) but when we upgraded to Core 2.2.x we ended up punting on the diagnosis migrations because we found a lot of outstanding issues that would need to be fixed and it was slowing down our ability to go to Core 2.2.x. Brandon, as reference:
We have a use case at one of our implementations where, for reporting purposes, when a clinician records a diagnosis whether it is the “first time” for that diagnoses (by “first time” is that the visit is the first for that incidence of the disease. So Diabetes will have only one “first time” diagnosis in a lifetime, but the flu might be a “first time” diagnosis every time the patient comes in about a new flu)
There’s no support for recording this data point in our current Diagnosis model, so I wondered:
Would there be support for making Diagnosis “Attributable” so we could store this as a “diagnosis attribute” (ie change Diagonsis so it extends BaseCustomizableOpenMRSData instead of BaseChangeableOpenMRSData) as @dkayiwa suggested in the previous post
If people had other suggestions on how to support it
I was also wondering if there would be any precedent for adding something specific to the Diagnosis model to support this. So, since I know we are trying to be as FHIR-compatible as possible, I wanted to look up the modelling of Diagnosis in FHIR, but after a quick look, it appears that there isn’t such a thing … it looks like in FHIR it would be modelling using a combination of Condition and Observation. Has there been thoughts of how our Diagnosis will fit in the FHIR model?
In FHIR, a diagnosis is generally modelled as a Condition. OpenMRS distinguishes between a Condition and a Diagnosis and FHIR does to based, essentially on the Condition.category indicating either that a condition is a problem-list-item for what OpenMRS calls a “condition” or an encounter-diagnosis for what OpenMRS calls a diagnosis.
Looking at the FHIR modelling, I’m not sure how one would represent “first time” other than, e.g., giving the diagnosis a clinicalStatus of active and making it the first instance of that diagnosis recorded for that patient.
“Repeated” sounds to me like it would be modelled in FHIR as a Condition with a clinicalStatus of recurrence; however, this valueset isn’t fully available in the equivalent OpenMRS concept.
A note on this: we’re unlikely to ever have a fully adequate solution to mapping between OMRS attributes and FHIR representations. One reason for this is that sometimes data that is represented as attributes in OMRS actually belongs in a standard field in FHIR (e.g., if we implement “repeated” as an attribute, it should affect the clinicalStatus rather than necessarily adding an extension). But we can certainly provide tooling to aid with those things.
In this case, however, it seems better to extend teh OMRS ConditionClinicalStatus enum to support recurrence or relapse as appropriate.
@bistenes I was looking through this ticket and the above conversion, Is this ticket still available to be worked or there is no need of adding the mentioned Fhir prescribed conditionClinitionalStatus constraints . If yes does history_of need to be removed since its not among the constraints
I would be skeptical of a “first time” flag providing robust data, since it depends on providers getting it right every time and isn’t something providers need.
On onset date is still hard to get reliably, but would allow providers to improve the data (e.g., update an onset date for diabetes even if the patient was diagnosed years earlier), would be more clinically useful, and you could still introduce a “first time” option in the UI if you wanted (it would just set the onset to today’s date).
Yeah this is actually a very idiosyncratic piece of information required by the Mexican MoH. What counts as “first time” is utterly non-computable.
Some examples: HIV is “first time” when it is first diagnosed. The flu is “first time” if it’s the first one in the season. Diarrhea is “first time” if it’s the first time the patient has come into the office with this particular case. There really is no other way to do this than to have a checkbox/radio specifically for it.
The question is then how we represent this in the data model—it is obviously not generalizable outside of Mexico.
I certainly don’t think we can remove HISTORY_OF, only mark it as deprecated / non-preferred. Otherwise, historical data could become unusable (and there’s no obvious migration path that maintains the same semantics).
I mean, the ideal would be to use the DiagnosisAttribute class available in 2.5 to store this data about a diagnosis. However, since the tag you’re using records diagnoses as obs, the best bet would seem to be to add a new obs to the obs group that’s already storing the diagnosis and it’s metadata to represent the value. Not ideal, but that way it’s stored in the same “place” as, e.g., “confirmed”.
The challenge is that there’s no easy way to do that that doesn’t involve one of:
Forking EncounterDiagnosesByObsElement and creating a distro-specific version of it.
Adding the code and a feature flag to the EncounterDiagnosesByObsElement in the core module.
Creating the diagnosis obs group using HTMLFormEntry’s normal utilities for doing so, by-passing a custom element.
From what I’ve seen, it seemed like you adopted 3 (to some extent). 2 is obviously a terrible idea, so I’d likely go for a modified version of 1, i.e., a distro-specific custom tag based on the existing tag that can capture this and render this data element into the appropriate obs group.
The reason I suggest onset date is because that’s what we’ve used to estimate the equivalent of “first time” by categorizing diseases of interest as chronic vs acute and using first time (e.g., if flu and diabetes are recorded on 2021-11-15, flu has onset of 2021-11-15 and diabetes has onset of 2010, then flu is “first time” and diabetes is not). In other words, when a provider marks something as “first time” they are effectively saying the onset is today. That information remains useful in perpetuity for chronic diseases.
