Background
Successful medical record systems consistently make it easy for health care workers to get the information they need for patient care in a rapid, lightweight way. Most often, clinicians are blissfully unaware of the technology underneath the user interface; and this often hinders their ability to find the information they seek. For example, while there are a lot of important reasons to store clinical observations as one question/answer pair per row, and demographics as attributes within specific demographic tables, clinicians often times simply want to select new patients or look for existing diagnoses for a given patient without having to know what part of the user interface what they're looking for. With the advent of the web and searching paradigms, an opportunity exists to apply well understood paradigms for web searching, to medical record system searching.
Purpose
The ultimate purpose of this project is to create a new UI widget (and module) for OpenMRS that has the ability to return search results based on a text query and to make this widget available throughout the web application. The initial steps towards this vision relate to creating the low level infrastructure to allow OpenMRS API services to register themselves as "searchable", and developing the basic API to perform searches across those services. This search bar would then be added initially to the web application header.
Domain Expert(s) / User(s)
Ben Wolfe, Darius Jazayeri, all implementers on the implementers mailing list :)
Required / Preferred Skills
- Java required
- Java Servlet / JSP development experience required
- Experience with developing search technologies preferred
Design
The search box should be a simple input box. The controller that receives that input passes along the text to every registered service.
My envisioned workflow:
- User types in "red"
- Controller loops over all registered services. (e.g. PatientServiceSearch and ConceptServiceSearch) (names can change)
- Controller calls PatientSearchService.search("red") which calls the normal PatientService.getPatients("red", null, null) and/or PatientSErvice.getPatients(null, "red", null)
- PatientSearchService returns all patients named red. The service was registered also said any patient that comes back should link to /patient.form?patientId=XX
- Controller calls ConceptServiceSearch.search("red") which calls the normal ConceptService.findConcepts("red", null, null, null)
- All concepts with red in the names/descriptions are returned. The results link to /dictionary/concept.form?conceptId=XX
- The displayed jsp shows all results linking to the different locations in the webapp.
The universal search module should not know about all the possible things that can be registered to it. It might register some of the core services to itself (like patient, concept, etc) but also expect other modules to register to it to provide their own searching possiblities. (e.g the logmanager module might provide a way to search the log files from that same universal search)
The results can either be shown in a new page or search+results can be ajax and in a popup under the search box. (The latter being preferred, but could introduced later if time is short)
Objectives
- Detailed workflow and software design for and development of the universal search box
- Develop OpenMRS service registration functionality
- Develop search API
- Develop early UI widget
- Register three OpenMRS doman objects (and their corresponding services) and make them searchable
Extra Credit
- provide mechanism of returning search results based on web application context (ie, what is returned when looking inside a patient record differs from when outside a record)
Milestones
- Midterm - finalized design of workflow and service, and basic UI in place (one object type).
- Final - registration functionality, extended search API, and multiple registered objects.