Hi, having been selected to work on the second phase of chartsearch module. As the Community Bonding Period is on-going, am figuring out how to transform the current User Interface into one of more usefulness and structure to it’s end users such as providers(doctors, clerks, nurses).
In the first place i must confess that am not a medical personnel and therefore my desired design may not be that of the user’s, so i would rather love to have their preferred view. Please suggest how better you would love to have physical components such as fields and the information appear on the patient’s chartsearcg page in case you would love to have a change of the way the current page is structured.
The current interface looks like:
Am going to make serious changes in the way am currently displaying diagnoses and some other things. Still the module is going to include more data such as allergies and appointments. All these i have not yet come to a conclusion on how i can physically get them displayed.
So the aim of this post is to collect thoughts on how better we can display the components and information to make it more useful. Please consider to look through my initially submitted proposal
@k_joseph, for each type of result, there is both a result display (in the list on the left) and a detail pane display (on the right). Are you using an interface for both of these? Ideally, each “out of the box” result type you support should be implemented through those interface, so they can serve as examples to module owners who want to add additional result types.
Try to avoid horizontal scrollbars at all costs.
Some features that I don’t know if you’ve yet addressed:
Keyboard navigation through results
Handling large numbers of results (paging vs. infinite scroll vs. a little of both). Infinite scrolling is convenient, but if placeholders are not used, then the scroll thumb does not imply the full number of results and, depending on how many results are fetched at a time, it can be laborious to get to the end of the list of results.
Dear @k_joseph, I like the initial design. Some questions or possible suggestions…
1.) As you start to type in a search string for patient data, does it automatically suggest possible searches as you type?
2.) How does this work with LARGE datasets? Is this going to fail or be painfully slow if a patient has thousands of diagnosis?
Thanks @burke and @arbaughj for your posts towards this topic in the first place.
@burke, your mention of result types gave a picture to me of making this more flexible to support modules, the first thought that came into my mind is the same page showing some sort of like selection component that allows choosing a result type (list containing like: default results, allergies, appointments) which would then populate the two result views respectively with the appropriate results and support the normal current behavior at a selection of one.
Keyboard navigation needs to be improved.
I will totally eliminate horizontal scrolling as you have pointed out and will most likely use both paging and scrolling at the same time.
No suggestions are currently supported but this looks a good idea that i will have to implement, may be just to know this as well from an experienced implementer as you @arbaughj; which suggestions would most likely be helpful? or what needs to be the source of suggestions! frequent searches, terms from the concept dictionary or any term from the English dictionary?
Currently the chartsearch page shows up even before the data indexing(performed on accessing/loading the chartsearch page of a patient) is done, i will be changing this behavior because it may make the user think that there were no results when actually indexing was still happening behind the scenes;
After the first page loading is done and indexing successfully performed, (this is what will most likely take more time depending on the number of result-sets from the database among other factors) searching and displaying results should be almost at the blink of an eye no matter the number of results returned from solr, and more results would just then be scrolled through or navigated around by paging. That’s my plan
Dear @k_joseph, thanks again for your continued effort to make this an even better module.
On the automatic possible search texts, I would suggest it be based on what you start to type, but there is probably a place for having provider one-click shortcuts (maybe frequent searches). I was thinking more of like an auto-complete based on the concept dictionary, but would not include suggestions for concept names the patient doesn’t have observations for.
Here are some ui mock-up diagrams that bring in the idea of making the UI flexible to support module data such as; allergies, appointments et-cetera.
I have three ways of making that happen the first is my best in the start.
1 . Using ui tabs:
This looks smarter but messes up the tabs as more displays are added to the module.
2. Using expanding sections:
This is better for as many displays as the user may add, this would work like tabs in functionality but would be horizontal and the labels of the tab would be headers to the section each expanding at a time.
3. Select:
This is pretty fine too though doesn’t get the display look as good as the first two and doesn’t display other displays until the selector is clicked on.
My choice as i mentioned is the first, however am welcoming more suggestions about the design. Just realized that i missed out something and so my next post here will be a better all component inclusive design idea.
This is my last UI thought for now:
the page navigation would be a break down of a display type into other sub display types like for the default display, we could have demographics, observations et-cetera
@k_joseph, I had always assumed that all of the different types of data would be merged into a single stream. As a contrived example, if I search for “pregnancy” I will find:
an obs saying “pregnancy test = true”
an encounter whose type is “pregnancy followup visit”
an appointment whose appointment type is “pregnancy - second trimester followup”
I could see having checkboxes that let you show/hide particular kinds of data, e.g. if you don’t want to see appointments in the result stream, you uncheck its box.
Yes @darius, that’s what is now happening with the supported results sub types, results are mixed up, but I thought having a way of representing them this way would be a better way for the medical personnel to find what he/she is actually interested in
This looks smarter but messes up the tabs as more displays are added to the module.
2. Using expanding sections:
This is better for as many displays as the user may add, this would work like tabs in functionality but would be horizontal and the labels of the tab would be headers to the section each expanding at a time.
3. Select:
This is pretty fine too though doesn’t get the display look as good as the first two and doesn’t display other displays until the selector is clicked on.
the page navigation would be a break down of a display type into other sub display types like for the default display, we could have demographics, observations et-cetera