While figuring out what i would then be convinced to be the best scope of my University final year project, i sent out for options from the OpenMRS community, one idea given being was pushing the chartsearch further, this was of much interest to me than other suggestions since working on the project for last (2014) GSoC had given me a wide picture of how much we as the OpenMRS community can achieve with Solr.
I spoke to the responsible academic persons at the university and they accepted my proposal, however they advised me not to submit my project any where else officially before the course is done which am doing. I believe that getting your thoughts about my progress in this line is proper guidance to keep me on track of having my work useful to the community after the project’s submission.
I then had to break down the needs of the project into two; one for GSoC 2015 and the rest for my Final year submission which will be happening in early May. I did this and had much work properly divided into the two sessions.
Am now working on the project and the progress is pretty good, The aim for this scope is to make the module the best tool any one in the openmrs circles will run to for any database searches, all that would be needed is, saving and indexing your need as a search project and then search. My task is to get the data to you in a way that makes it possible for you to at the client level overwrite my fake initial display of it, this would add value to your results.
Another thing is that, the requirements pointed out that i needed to make my project useful to someone outside openmrs and so, i thought of extending it to index and search against data outside the database the running openmrs instance.
Here are a few screen shots taken from the current work progress to help you envision this well:
Indexing data from the openmrs database:
Indexing data from a non openmrs database:
Choose a Project of the existing ones to update, shows non details by default unless one is selected from the drop down:
Almost all custom-indexing tasks are done, i will be working on Non-Patient searches beginning from tomorrow where the searching will be taking place
@k_joseph, do you have any mockups/examples of how non-patient searches might be used?
I notice you have “Filters” as a separate tab. Aren’t filters going to be specific to the subject of the search (e.g., the filters useful for searching a patient’s chart would be different than filters useful for searching other domains)?
From a high level, I would think that non-patient searches would be lower priority relative to leveraging SOLR to perform aggregate searches (e.g., find all visits across all patients during 2014 with a new diagnosis of diabetes).
Thanks @burke for the response, my thought about the filters tab was, controlling which filters can show up, define custom ranges like dates among others, however this functionality was based thought of for non-patient searches.
First of all, we had a discussion with @dkayiwa today on the IRC which made me to decide pushing non-patient searches into totally a separate module. (Am soon going to write about that to the community). BASICALLY, this would leave chart search to handle only and all patient related searches.
I get your suggestion; searching across all patients (still patient centric). All these good thoughts, am accepting and getting them in my mind though having them piled up for GSoC. I just didn’t want to get such tasks into this Final Year project scope.
Currently this work is being done in a separate branch off upstream openmrs-module-chartsearch master, and am hoping to move it to a separate module (multi-search). For now i want to write about the new module to establish whether the community needs it since it’s in progress. Am thinking that it can be useful to us and non openmrs searches.
I agree with Darius’ comment, allowing other modules to add data to the searchable chart is an important next step. I would imagine that this would involved at least three things from the module:
Data to be indexed, including convention for labeling so the new data could automatically show up in the filters.
Optional custom result display handler(s), allowing a module to define how results for its data should appear. If not specified, a generic result display would be used.
Optional custom result detail display handler(s), allowing a module to define what should be displayed in the detail pane when the result is selected. If not specified, then a built-in detail display would be used based on the inferred datatype (numeric vs. text).
Allowing searches across patients would be less of a priority, but I’m sure folks would appreciate it. I can see a simple way to implement this and a more powerful way…
Simple approach: make the first filter a patient filter. Chart Search could work as it does now by simply defaulting the patient filter to the selected patient. But the user could select the patient filter and select multiple patients or specify one or more cohorts to perform searches across all of those patients. Alternatively, they could remove patient filtering by selecting “All patients” in the patient filter. Whenever the patient filter was set to anything except a single patient, the results (and probably detail panes) would need to specify the patient. Â
More powerful approach: making a separate module focused on population searches. This would allow you to summarize counts more clearly and more cleanly match the expectations of someone searching for aggregate results – i.e., assuming someone searching a population is less interested in specific results and more so in aggregate counts and trends.
Thanks Burke, are you suggesting that approach 1 should be on the same current chartsearch page we have! I think i would need more look into approach 2. I will be putting more effort for now in module data searches
