Some help needed for list options

OpenEMR Development
#1

Hi,
Could someone help me to figure this out: how to restrict list options in one field (new patient entry form) based on an option in another option list field? which php files need customization, I cannot find a way in the layout editor to do that…
The reason for that is our “breeds” list in the veterinary version of OpenEMR is very long, it lists all possible breeds of the normal species we see in the clinic. It makes finding the right choice difficult and not fool-proof. So when I choose “canine” in the species list, the breeds list should only show canine specific breeds. The breeds list is using the VeNom codes (Veterinary Nomenclature) that I worked into OpenEMR.
Any ideas where to start looking? thanks
Roland :paw_prints:

#2

@roland,

You can create the drop down in layout and create the separate list for every layout drop down filed. Then you need to write the jquery ajax code and onchange function and select the list that are selected from layout drop-down.

Thanks,
Nilesh

#3

@Nilesh_Hake,
Thanks for your reply. I am not exactly sure what you mean, but if it is creating a separate B (breeds) list for every item in the A (species) list, it will be impractical: the A list of species has 63 items at the moment and it is growing every month. The B list (Breeds) is 1245 items long and that will expand even faster. So the most practical solution is for list A to decide what list B can show to the user. If I had to create many separate lists for the B list it would be very hard to maintain. Or did you mean another solution?
thanks,
Roland

#4

Two ways to do this but requires some coding. 1) add new data type for maybe a select from lookup ie select2, where the look up term would be species to qualify the breed list.
2). modify the conditional item feature to include picking from lists.

Both of these can get rather involve if you don’t understand layouts code. doable though.

#5

@roland,

For this feature coding is require, please tell where should have need to implement this in openemr and requirement for this, then I can tell you exact what you need to do and which file needs to modify.

Thanks,
Nilesh

#6

Hi @sjpadgett @Nilesh_Hake,
Thanks, it seems that the best way to do this is Jerry’s option 1, and that I will need to add a new data type to /interface/super/edit_layout.php, and add the code for the data type in /library/options.inc.php, or is there more?
O deer :deer:it will require coding, :nerd_face:but I guess if we can get that done, it will be very useful to the human OpenEMR community as well, not only to the other species…
I’m not sure I understand everything in detail that’s being done in edit_layout.php, but I can tell that adding the type and controlling the results is done there, and the code for looking up and picking from a list is done in options.inc ??

#7

@Nilesh_Hake,
on second thoughts, I looked at some files yesterday; if it can be modified in the conditional item feature (the ? pop-up) on the administration->layouts editor I probably only have to change one file instead of 3. Can you help with that?
Thanks
Roland

#8

@roland,

Yes will definitely help you, please find my below email id nbhbiotech.hake@gmail.com for further discussion.

Thanks,
Nilesh

#9

Why did you take this offline?

#10

@sjpadgett,
I don’t know, should I be concerned about this?

#11

No, I was just following to see how you guys attack this issue. That is what the development category is about after all.

#12

Not yet sure how, but after reading through the edit-layout.php, I think adding an option into the conditional item feature seems the most logical. It’s not really a new datatype, just a field taking a value from another field. Adding a datatype would require also changing options.inc.php, am i right?
AlthoughOptions.inc is easier to understand than edit-layout for a weekend vet developer :weary:

#13

@sjpadgett,

I will update the progress here and steps that we will follow to achieve the goal.

Thanks,
Nilesh

#14

Thanks but you don’t need to do that. This was a thread that piqued my interest and was enjoying following without interjecting myself too much. Do as you guys find easiest.

I do believe that the conditional had intentions of handling a feature like this but was never carried out

#15

Hi @roland, @sjpadgett

Please find the below flow that I am thinking on above problem:

  1. We need to create the new data types into layout i.e “Select repose” and that will be the drop-down list.
  2. If any one have created this data types on there form they will able to see automatically additional field on changing above field value.
  3. Every value of the selected repose data type are associated with respective fields list that want to show.
  4. Once user changed any fields they will be able to see there respective lists automatically.

Please let me know if any questions on this or any suggestions on this.

Thanks,
Nilesh

#16

I’m wondering if it would not be simpler to just use a drill down of one select list of breeds.
@roland The problem as I understand it is the breed list is simply getting too long to have to scroll into for selection. I would think the user would know the breed to select, regardless of species, so preselecting species is really not needed. It is much easier to narrow the breed list using a search box(select2) to do a lookup after the first 2 or 3 characters.
This way one can add a new data type, List Drill Down or List w/ search etc, with simply following an existing list data type through code as example for adding data type.

Also @Nilesh_Hake , if you decide to use a primary(species) list to delimit a secondary list(breed) one might capitalize on the fact that list data types offer a backup list. You could simply add an option(flag) to existing list designating that the two list (primary and backup) are dependent on one or the other for search term qualifier. This way one could display the two list as a set or component.

Just a couple thoughts.

#17

Hi @sjpadgett,
thanks, it’s true that the breeds list is getting too long. The way almost all the forms, the CDR’s, the (VeNom) coding system, color specifications for ident etc. are setup is that they change the logic and appearance according to the “species” value list (stored as a numeric value), it’s a required field because of all the considerable anatomical and fysiological differences (birds can be blue or brown, but I never had a turqoise dog or horse in the practice…). The application doesn’t work without it. The breeds field is also used for stats & probability of certain problems or diseases. But I think you did not mean to ditch the species field, just ignore to it, however, here is another thought: in some cases the user is not sure about the breed presented (this happens more often to doctors than the front desk…:wink:) and narrowing down the almost endless breeds list can be very helpful in suggesting or reminding, without having to ask the owner and loose their dignity, or just plain when there is no owner present (a stray or found animal). So the delimiting function is not a luxury, I can think of many other situations where it could be useful. In another situation the primary element could also be a checkbox or a radio button.
thanks for your input, really appreciate it

#18

@sjpadgett,
o, and I always wondered about the backup list thing in the layout editor, I can’t see any form using it, and why it is there, but your suggestion @ nilesh is interesting. So by making the primary and backup list dependent on each other we could solve this also? I’m going to sleep on that one and hope the solution will magically have come in my dreams tomorrow morning…