Project Proposal
- Zhaslan Doschanov
Original proposal at google meelange is here.
Abstract.
Patients are the heart of every medical record system. OpenMRS is not an exception. A lot patient information (visits, encounters, observations, etc.) should be easy to find. Chart Search goal is simplifying patient related necessary information search. End user can just type search text and instantly see search result from different types of content with short description of every record. Lucene and SOLR can help accomplish fast searching by indexing content. Ideally it should be 2 modules: 1st module index data using SOLR or Lucene and provides API, 2nd module provides UI and uses 1st module API. But first version of Chart Search will provides both indexing, searching, UI. Embedded SOLR or Lucene will give us indexing and searching possibilities. Encapsulating everything in one module is a first pass, it makes easier to install and use for the end-user. Also it makes easier to find all pitfalls and avoid them in the future.
In this project I’m planning to do:
1. Create module. Add Embedded SOLR or Lucene.
2. Provide mechanism to index patient data.
3. Provide search mechanism. Merge results from index with database records. Check user privileges.
4. Provide initial UI for searching.
Project Implementation Plan
1. Create module. Add Embedded SOLR or Lucene.
Issue: Chart Search should be separate module we can easy install/uninstall from modules admin page. We need full text search capabilities.
Solution: Create Chart Search module. To add full text search capability use Embedded SOLR or Lucene. Using Embedded SOLR has some advantage over Lucene: easier to switch to separate SOLR server, REST-ful interface, many additional features (query extensions, faceted search, etc.). It is OpenMRS “proof of concept” module https://github.com/dkayiwa/openmrs-module-solr that uses Embedded Solr.
2. Provide mechanism to index patient data.
Issue: Fast search cannot be accomplished without indexing data. But indexing/reindexing all data can take a huge time, index will take many space.
Solution: Index/reindex patient data only when you access it (do it in the background).
We can do this using Hibernate interceptor. Only thing to do: override onSave or postFlush method. HibernateSessionFactoryBean class autowires all declared in applicationContext (or moduleApplicationContext) interceptors and saves them in ChainingInterceptor. ChainingInterceptor is some kind of interceptor’s wrapper or decorator. It sets as interceptor in Configuration. Possibly user will not find all results, but it will not require additional resources to use Chart Search Module.
3. Provide search mechanism. Merge results from index with database.
Issue: Containing all data in the index is not efficient. It will lead to huge index that requires more disk space and bit slower.
Solution: Store in the index only important searchable parts. SOLR query result will contain only ids. Data will take from database by these ids. After database results will merge with embedded SOLR (Lucene) results that provides some addition features (e.g. SOLR text highlighting). Queries to database will go throw OpenMRS API (PatientService, EncounterService, etc.). Probably we will need to add some additional functionality there.
We should return results according user’s privileges (OpenMRS has built-in @Authorized annotation). If user doesn’t have privileges to see search result, we can put placeholder. It will help to avoid some pagination problems.
Embedded SOLR (Lucene) search API can be encapsulated in some Search class (classes). It will help to switch to dedicated SOLR server in the future.
4. Provide intitial UI
Issue: How user can search if he even can’t go to the search page?
Solution: Add JSP page with simple UI interface. Interface will contain search box, results area, result short description area, possibly filters (date ranges, facet search, etc.) and sorting area. Use Ajax to show row short description on result row selection.
5. Extra Credit
a) Add opportunity to use separate SOLR server. It should be easy to end user: something like two lines in configuration file – use separate SOLR server and server address. To accomplish this task using Lucene or SOLR should be encapsulated.
b) Provide more advanced UI. Add graphs, filters, sorting. Possibly use Flowsheet module functionality (add dependency to Flowsheet module).
c) Add opportunity to index everything and re-index “on demand”. Will be good to implement two indexing approachs and give administrator choice which indexing way he wants to use. If it is not too much data or administrator have many resources it can be useful feature.
d) Move functionality to distinct modules (e.g., Indexing module and Chart Search module).
Use Cases
There use cases show functionality, if all steps will be finished.
https://openmrs.atlassian.net/wiki/download/attachments/16318469/OpenMRS+Chart+Search+-+User.png
UI mockups
Project Time-line
27th May – 10 June : Will not be available due to the final exams at university.
11th June – 17th June : Going deeper to required technologies, getting to know the mentors, prepare working on the project
18st June – 29thJuly : Implementation of Step 1 and Step 2. Initial work on step 3.
29thJuly – 2nd August : Midterm evaluations
3rd August – 10th September : Implementation of Step and Step 4. Possibly working on Extra Credits.
11th September – 26th September: Testing the code, writing the documentation.
27th September – 1th October : Final evaluation.