Encounter Diagnosis Widget

Development
1

I came a cross this https://github.com/openmrs/openmrs-module-coreapps/blob/master/api/src/main/java/org/openmrs/module/coreapps/htmlformentry/EncounterDiagnosesTagHandler.java#L20 and wondered how can someone add there own? I recently created other diagnoses in my dictionary but apparently I can’t access them using this widget, any help?

2

any thoughts @darius @dkayiwa @mogoodrich

3

Is it in any way related to this? How to use the encounterDiagnoses tag in HTML Form Entry?

4

Thanks @dkayiwa. Yes, this is referring to the same widget.

I had to refresh my memory, but it looks like this widget is hardcoded to search and use only concepts with a mapping to the “icd-10-who” concept source. If you don’t have this source in your system, no concepts would show up when searching.

However, it would seemingly be straightforward and valuable to allow implementer to specify a different source to use, or perhaps to specify by concept set. What would work best for you? I think it would be worth ticketing.

Take care, Mark

5

Hi @ningosi, were you successful using the Encounter Diagnosis Widget? What procedures did you follow?

Looks like some work was done to use registered sources via GP but some how I can’t figure out what could be missing for the widget to work correctly given there are existing diagnoses in the dictionary for the registered sources.

Thank you very much.

cc: @ningosi, @mogoodrich, @dkayiwa, @mksd

6

@ruhanga created this:

  • RA-1598: Allow for client-side filtering of diagnoses by concept sources specified through a tag attribute
7

Hi all,

While working with @mksd on capturing encounter diagnosis, it is required that a defined set of diagnoses or super set of diagnoses sets is/are used to capture patient diagnosis within a given HTML form. Our understanding of EMR API is that the superset of diagnoses used is defined globally through a GP (traced from here), and there is need to restrict that pool of diagnoses to capture only from the required subsets or sets.

Is such an approach as extending the search term with an option defining the diagnoses set to use keeping in mind backwards compatibility, for example diagnosesSet=8b94e209-8ca2-4b76-9458-bec4017f3e67 in the example below a viable solution?

http://localhost:8080/openmrs/coreapps/diagnoses/search.action?term=example-term&diagnosesSet=8b94e209-8ca2-4b76-9458-bec4017f3e67

Thank you.

cc @mogoodrich, @ball, @darius

8

@ruhanga You explained this well, but I’m unclear about the URL. How do you expect to use this?

You didn’t ask, but I’m providing a little more context for our implementations. We are not currently using encounter diagnoses. You are correct that we use a superset of diagnosis sets which we use for reporting and specific forms. For example, we might not capture orthopedics surgery diagnoses during an oncology encounter. We might want to report on all NCD diagnoses (NCD diagnosis set) which are captured through-out the health facility.

9

@ball the URL is not really used directly, what @ruhanga means is that we would like to expand the signature of the controller behind that URL, so that diagnosisSets can be overridden:

Ok that’s surprising, could you share some background on the reason behind that?

1 Like
10

What I believe @ruhanga is asking from a functional side is, would it make sense to add an attribute " diagonsesSet" to the Encounter Diagnosis tag to allow specifying a specific set of diagnosis to use (thereby allowing the creation of different forms that search different diagnosis sets).

This definitely sounds valuable to me, and I think your solution makes sense as a way to implement it.

Note that I’d have to refresh myself on the details, but in 2.2 “diagnosis” became a first-class citizen in OpenMRS with it’s own table (“encounter_diagnosis”)… at PIH we have upgraded to 2.2 but have not migrated to this new modelling, which is the distinction I believe Ellen is referring to. We do use the “EncounterDiagnosisByObs” tag which is a 2.2+ tag that supports saving encounter diagnoses using the pre-2.2 model (as obs).

In Core Apps there is:

  • Pre 2.2 EncounterDiagnosisTag (stores diagnoses using Obs)
  • Post 2.2 EncounterDiagosisTag (stores diagnoses using Encounter Diagnoses)
  • EncounterDiagnosisByObsTags (identical to pre-2.2 EncounterDiagnosisTag, but available in 2.2+)

Hope that makes sense!

Mark

1 Like
11

Related ticket, for reference:

12

@mogoodrich actually we have refined the analysis a little and there are two distinct tickets now:

13

Offhand I can’t think of any reason not to add an (optional) parameter that overrides the GP-configured set-of-sets.

14

Btw @darius about this one we have drafted this:

I know that the current code base rather invites us to override the set of sets, but practically it is much more useful to override with a list of sets. Typically: “I want to pick only from NCD diseases here” and therefore we could pass a 1-element list containing the ‘NCD Diseases’ set.

Thoughts? @mogoodrich, @ball?

15

@mksd agreed, that makes a lot of sense, to pass a list of sets instead of a set of sets… (or potentially we could support both, but I agree that a list of sets is the more important one).

16

@mksd Agree with @mogoodrich

FYI - These are our set of sets.

  • Pediatric diagnoses
  • NCD diagnoses
  • Outpatient diagnoses
  • Psychological diagnoses
  • Womens Health diagnoses
  • Emergency diagnoses
  • Surgery diagnosis
  • Oncology diagnoses
  • Dentistry diagnoses
  • Internal medicine diagnoses
  • Orthopedic diagnoses
  • Pain diagnoses
  • Rehab diagnoses
  • Dermatology diagnoses
  • Opportunistic infection diagnoses
  • Hypertension diagnosis set
  • Heart failure diagnosis set
  • Respiratory diagnosis set
  • Diabetes diagnosis set
  • Sickle cell diagnosis set
  • Renal disease diagnosis set
  • Maternal diagnoses
  • Complications at delivery set
  • Pregnancy danger sign set