Multi select in new drop down format

Is there any way you can multiselect from each list in the new way of entering data from the dropdown, for example in history. You might want to enter more than one option form a dropdown

I was thinking this today too. There are occasions when you would want to select more than 1 option from each list for the history pop-up.

The pop-ups do allow multi-select as a property (e.g, see medications, systemic diagnoses, etc), but not sure if it is currently supported for multi-list-multi-select!

I’ll ask and see.

This has now been added to the development queue and should make it into 3.0

1 Like

…and here it is (develop instance)

Currently each column is set for multiselect- but this has worked with rules- for example the eyeside column should be single select.

There is a wider context to the use of popups- in that they are starting to blur the difference between edit and view mode. We can do more in the popup - for example in the history popup- we could edit the text box within the popup so that the view when the box is saved is the same as the saved view mode. We will effectively have in line editing without expending too many resources. If you check examples on the idg site you will see that we are experimenting with this option (and IMHO) I think this works.

This looks really good and would be a great improvement in functionality.

One question in my mind is with any items selected in these pop-ups, will the data be coded in such a way that it can be interrogated at a later date for audit/research purposes?

A simple example would be if for instance we wanted to look at outcomes for patients with retinal detachment, could we use data from the history element to compare those with a history of 1 week or less with those of mo
re than a week?

yes- this is just front end remodelling- the data model remains the same. I will check with Toby that the dates are in date format rather than strings- but even if strings they can be queried.

@ian.rodrigues - The history comment itself is plain text. While it could be queried for specific strings, it isn’t structured data.

However, given the example in your comment, you could still determine the patients with > or < 1 week from the first diagnosis date or appointment dates (which are of course structured data).

You’ll find that almost everything that you could think of to query for audit/research is captured as structured/coded data somewhere on the form.

Many thanks for the clarification. I thought that was the case that it wouldn’t be true structured data, but good to know it could be searched for in some, albeit less simple way.

For the example I had, I don’t think you could actually determine it from the first diagnosis date as in clinical practice this would most likely end up being recorded as the same date as the first appointment (when the diagnosis was made), rather than the date when the symptoms occurred (which may or may not coincide with when the problem first occurred) .