Hi dear reader;
Finally here is my GSoC 2014 mid-term presentation,
Project:
Chart Search for the Reference Application
Assignee:
KAWEESI JOSEPH
Mentor(s):
DANIEL AND TOBIN
IRC nick:
k-joseph
The Chart Search module uses solr to index, search and filter patient data, in my video presentation i have captured the current state of this project and mentioned something about the up-coming tasks.
I mainly need your feedback on current and up-coming issues, what do you think about filter categories, search syntax and searching forms?
Please respond with any thoughts or questions and we shall be willing to answer as much as we can,
Here are some abstract tickets we have for some of the above mentioned tasks in my presentation;
https://issues.openmrs.org/browse/CSM-58 | Define Categories
https://issues.openmrs.org/browse/CSM-25 | Define search syntax
https://issues.openmrs.org/browse/CSM-56 | Searching forms
Wow, fantastic job Joseph. I think this work has a very good shot of being evolved to become a fundamental core part of the OpenMRS 2.0 Reference Application. Would love to hear from @darius on this. I’d also love to get my hands on a test version of this.
Questions:
Can we work with you to get a live demo of this up on a server somewhere?
I understand the ideas behind SOLR/Lucene pretty well. I’m happy to see you’ve embedded it, but I’m curious to hear about the tradeoffs from you. For example:
2a) How big are the data blobs for a given patient (in terms of disk storage)? How are you handling persistence? Are you just leaving this to SOLR at the moment?
2b) Viewing an individual person’s record seems super speedy/nice, but how long does it take to load a person’s record? Is the work to persist content in Lucene being done on the fly upon a record selection, or is it being done as a cron job in the background?
Are you interested in taking a leadership role in evolving Chart Search over the longer run after GSoC?
Is Tobin serving as your medical domain expert? Have you involved @burke in design yet? He has a lot of experience building such functionality in the past.
Filters:
not sure that datatype will be as interesting clinically…
providers are much more complex than a drop down list. You could consider showing all providers linked to observations, and let people choose from among them, or do a text search for providers. The most important one is likely “me”, referring to the provider who is using the system at the time
can you please explain how “categories” works a little more fully? I didn’t understand how you chose to implement
Test batteries (collections of tests that are commonly ordered together) are typically built using concept sets. This is how you can show systolic and diastolic blood pressures together, alongside other batteries. Have you talked about that at all?
blood pressure should match something like (blood or blood*) or (pressure or pressure*). If someone wants to restrict to the phrase, they can use "blood pressure" (double quotes around phrases).
Your detail view should never be blank. Whenever you render/update results, start with the first result selected and its details in the detail view. A user should be able to see the most recent result and any details about that result for the patient (within the detail pane) without any additional interaction.
As @paul said, data types is useless as a filter. Users do not know or care about this detail (nor should we bother them with it).
If you want to filter by provider, then you’ll need a search within the filter itself (which might get messy or confusing), since implementations can easily have hundreds of providers. Alternatively, make the provider show within results and/or detail clickable links that will filter to that provider.
For filters that allow multiple select (i.e., Categories and I assume you will want the same for Locations), allow single-select by clicking on the label. This way, users can use the checkboxes + OK button for multiple selection and click on the labels for the more commonly useful one-click-single-selection.
If you can’t easily get a server for demonstrating your work, take a look at DigitalOcean, where you can create a machine in 60 seconds, install OpenMRS w/ your module, and host it as needed. Keeping it on can cost $5-10 USD/month, but keeping an image and spinning it up in 60 seconds as needed for demos can be done for mere pennies.
Have you got a 1.0 (or is it 2.0) version of your module done yet? I would suggest deciding on the bare minimum functionality needed to make the module useful out-of-the-box (you’re nearly there now from what I see) and get that released to the community as soon as possible before considering more features or enhancements. Go into the last part of GSoC with a release already done; otherwise, if you let the summer end with your module 99.9% done, it may never get used.
Strong work! You’re doing such a fantastic job as Release Manager for OpenMRS Platform 1.11 that I forget that you are also doing a fantastic job as a GSoC Intern as well!
Hi @paul and @burke, thanks please for your wonderful replies, Am glad to see your questions, sugestions among other thoughts you have about this project.
Am willing to work with you(@paul) to get a live demo of this
module on a remote server, please let me know when we can do this. @burke has suggested http://digitalocean.com/ and let me visit their website as soon as i write this reply.
For now we are leaving persistence to solr, and we are idexing each patient’s data seperately, we add patient’s data to the index when the user requests the patient’s dashboard page after which we just update the index to include any new data, rather than posting all patient data to solr at once. currently my index is still small, i will update you about the size after indexing over 5000 patients.
Am very interested in taking a lead role to evolve the chart search module even after GSoC and appreciate @burke’s view of having a release to the community even now, let me speak to @dkayiwa and Tobin about this so we can release another version since so-far we began with 1.0 that was done by Dragggonz last year and are still working over 1.0, though i would appreciate that after i have finished the category filter.
@paul: Tobin is really of good help in all these and he is serving as our medical domain expert indeed, @burke is also replying and following up very well and his guidance has brought us much far to where we are now, i will keep on consulting him whenever i need to. (thanks for your reply @burke about search syntax, let me consider that in my next interations).
About categories, we have several filters like; categories, time, locations, providers and datatype, and we are going to discuss with the mentor(s) and eliminate those filters that may not be much useful to the user. of all filters, categories and time are most important even according to me and so-far we are using available concept classes, we indexed concept class and also made it searchable, then later on use that field to filter results according to concept classes such as diagnosis, labs, meds, among others since each result is associated to a concept class for observations.
Still i intend to use faceting for this since it offers us a way to view counts and also drill down or select some or any category(ies) as described by @burke in his last about filters.
We will consider displaying a detailed view of the first result whenever a search is done so we always have to display some thing in the detailed view. i will consider doing much of this after writting category filters.
@paul: We have not yet talked about test batteries … i will be contacting @dkayiwa and Tobin so we can discuss that with them plus you.
Thanks once again,let me know in-case there’s somewhere where i need to throw more light.
Hi devs
I last week added the category filter to the module and it is working well, you can test it out and suggest what you think about it for what we so-far have on it, you may check it out from the module’s github repository.
@k_joseph, great work so far, and it’s wonderful to see this! (And sorry that I’m just watching the presentation now!)
This is definitely something I’d love to see get included as part of the Reference Application. We’ll definitely need to look into the performance implications and server requirements, as Paul hints, so let’s let this be an evolving discussion. (I also noticed that it may be hardcoded to English, so we’ll need to figure out how to internationalize the indexing.)
One further question: have you given any thought as to how you’re going to visually represent Obs Groups? E.g. in OpenMRS 2.0, in the Visit Note, you can record a diagnosis, which is not just the specific diagnosis, but further attributes as well, and each diagnosis is stored as an obs group with 3 obs members. For example: diagnosis=Malaria, order=Primary, certainty=Suspected. So, if I search for “Malaria”, I don’t want to see just diagnosis=Malaria, but also the other obs in the group.
Also, it would be great to be able to have a shortcut (I think like you have for CD4 Count under Categories) for Diagnoses, so hopefully there’s a way to customize these depending on the OpenMRS distribution.
Thanks @darius for your response, in this GSoC we have mainly focused on the major functionality of the module. i will afterwards be continuing with evolving the module plus any other interested devs,
About internationalizing the module i will consider creating some tickets where other contributors may translate our messages and will work upon all hard-coded messages so we can support other languages.
About the further question, we shall discuss it further with @dkayiwa. and Tobin.
So-far with the code we have at the module’s repo, as long as the patient has diagnoses stored for, we return that category for filtering, we are considering to have some categories show up even when there is no data for that particular patient later on. then also we hope to add a way of customizing categories afterwards
