Target: Successful completion of this project would at the minimum, enable an administrator within an OpenMRS implementation to define a hierarchy of locations and for the location search page to respect that hierarchy — e.g., select from locations within a particular level.

Encounter Type Hierarchy

Mentors: Burke Mamlin

Abstract: We would like to be able to group encounter types. As multiple types of encounters are entered into the system, we often end up with entries like "ADULT INITIAL VISIT," "ADULT RETURN VISIT," "SEROLOGY LAB REPORT." Given these, we need to be able to identify which encounter types represent patient visits, versus lab visits, etc. The current thought is that adding a encounter_type_parent as an attribute of encounter_type that links back to encounter_type_id. This would allow encounters to be arranged into useful groups. To make this happen, the data model, the API, and some web interface pages need to be adjusted accordingly.

LDAP Module

Mentors: Ben Wolfe and Burke Mamlin

Abstract: One of the goals of OpenMRS is to find ways to interact with other complimentary systems. When multiple systems are being used together, unified authentication (single sign-on) can greatly improve the user experience. An LDAP module for OpenMRS would override the existing authentication scheme and instead use a connection to an w:LDAP server to authenticate users within OpenMRS.

Module Data Removal

Mentors: Ben Wolfe and Brian McKown

Abstract: There should be an option on the administration page to remove all module data when removing a module. This would require a change to OpenMRS Core code as well as changing existing modules to include this feature. See ticket:643.

Global Property Types

Mentors: Mike Seaton and Justin Miranda

Abstract: Add types to the global properties table to help guide users when entering the data. Currently all global properties are assumed to be strings and are just stored as key-value pairs (with a description) in the database. They could still be stored as strings in the database, but if they also had a notion of a type, then the user could be given a Concept selector, or a date picker, a password textbox, or a User selector depending on the Type of global property. Read more on ticket:645

Firefox Addon For XSN Downloads

Mentors: Burke Mamlin and Ben Wolfe

Abstract: Create a Firefox AddOn that allows XSN downloads to bypass any dialogs — e.g., bypass the download dialog to open InfoPath documents. This would need to be done in a relatively secure manner so as not to open a giant security hole in Firefox. We believe that an AddOn that bypassed the download dialog for only user-specified mime-types and then only for named (trusted) servers, it would be both safe and useful. See ticket:175.

Data Synchronization: Comprehensive Unit Test Framework

Mentor(s): Maros Cunderlik and Christian Allen

Assigned to: ?

Abstract: Data synchronization is a new OpenMRS feature allowing synchronization of data amongst a set of loosely networked servers. Such ability to exchange data is essential for operation of EMR system in rural areas where connectivity amongst sites maybe unreliable yet the need for timely centralized collection and analysis of data from remote sites exists.

Distributed and loosely connected nature of the environment this feature is designed for highlights importance of maintaining accuracy of collected data and added difficulty of detecting results of code bugs that otherwise maybe noticed and corrected more rapidly. To that end, development and testing of data synchronization can greatly benefit from extending core OpenMRS junit framework to synchronization with coverage of all core domain objects and API. The challenge is to do it in a clear, reusable pattern while leveraging any existing junit tests for the core API as to avoid duplication of setup data and test case code.

Data Synchronization: Adaptive Data Transfer Algorithm

Mentor(s): Maros Cunderlik and Christian Allen

Assigned to: ?

Abstract: Data synchronization is a new OpenMRS feature allowing synchronization of data amongst a set of loosely networked servers. Such ability to exchange data is essential for operation of EMR system in rural areas where connectivity amongst sites maybe unreliable yet the need for timely centralized collection and analysis of data from remote sites exists.

As observed during the initial deployments in some areas, the transfer rates of data and data corruption issues over unreliable connections can vary widely. It is not uncommon for connectivity in remote sites to be in a state where 'it works but one cannot transfer any data'; i.e. basic protocols work but attempts at data transfer of any significant size (i.e. > 50KB) fail. This presents a unique challenge to data synchronization: how do we maximize transfer rates over networks with widely varying characteristics without undue burden of manual administration setup and monitoring? The goal for this project is to develop adaptive algorithm where the synchronization would adapt to the quality of the underlying network connection and automatically adjust frequency and size of data transfer packages with notifying administrators only in cases of prolonged or complete outage.

Approximate Date Support

Mentor(s): Darius Jazayeri and Burke Mamlin

Assigned to: ?

Abstract: Computers (and therefore databases) understand dates very well; however, dates are often treated as a specific data type that does not allow for any fuzziness. In clinical practice, we often are only able to estimate dates. For example, many patients showing up to clinic in developing countries do not know their exact date of birth. They may know the month and year, they may only know the year, or they may only know an approximate year.

We would like to be able to represent these "fuzzy" dates more flexibly than we do now. Currently, OpenMRS stores a person's birthdate along with a boolean flag to indicate whether or not the date is estimated. This project would aim to give us more flexibility in specifying exactly which parts of the date are estimated. See Ticket #430 for more details.

Some ideas for this project:

• Examine the data model for where we store dates AND an estimated flag — these would be the initial targets for the "new" more flexible date handling (e.g., person.birthdate).
• Simply converting the existing column from boolean to a small integer would probably suffice to store the additional information.
• You'd need to work through how these changes would affect the user interface wherever these dates are entered or displayed. In some cases, this additional flexibility in estimating dates may allow for improvements in the user interface.
• Patient search results could be improved so the birthdate displayed reflects what is actually known — i.e., we could display month and year if only the day is unknown.

Target: Successful completion of this project would allow OpenMRS to store and render approximate dates for patient birth dates and date of death. Bonus points for patching the HL7 processor to accept approximate dates for these values. Super-duper bonus points for enabling approximate dates within other aspects of the system — e.g., observation dates.

Active Projects

Patient Portrait Support

Sample patient image from our WIP UI refactoring

Mentor(s): Dave Thomas

Assigned to: Mamadou Diallo

Abstract: Identifying patients may seem simple or trivial, but it turns out to be a very important aspect of what we do. Many countries do not have national identifiers, so we end up relying on name, birthdate, and a few other details to try to uniquely identify patients. A well-known proverb says "a picture is worth a thousand words." To this end, we would like OpenMRS to be able to store and retrieve portraits of patients so the patient's picture could be shown when their record is opened within the application.

Some ideas of how this could be implemented:

• Most likely, this would be achieved by creating a module that adds a person attribute for the patient's photograph as well as the tooling needed to upload a picture.
• The module would also add the photograph to various parts of the user interface.

Target: Successful completion of this project would at the minimum allow a end user from within OpenMRS to upload a patient's photograph and then render the photograph within the patient dashboard.

Structured Numeric Support

Mentor(s): Darius Jazayeri and Burke Mamlin

Assigned to: ?

Abstract: While the vast majority of numeric results for a clinical information system are either stored as whole integers or fractions, there are a number of numeric values that have more of a structured form. For example, ranges such as "5-10", "<=5" or ">10"; ratios such as "1:2"; and qualitative responses mixed in with numeric responses such as "too many to count". Within our database design, we have provided for a datatype to express these data: the structured numeric datatype.

The structured numeric datatype is used to unambiguously express numeric clinical results along with qualifications. This enables receiving systems to store the components separately, and facilitates the use of numeric database queries. We would like to see native support for this datatype at the API level within OpenMRS.

Some ideas of how such a feature would be implemented:

• Review and adopt the HL7 conventions for structured numerics
• Modify the concept and obs services to add support for this datatype
• Build the conventions for the numeric modifier code set
• Create conventions for rendering these results in-line in a similar fashion to typical numeric results

Target: Successful completion of this project would at the minimum, enable an OpenMRS implementation to create concepts with a structured numeric datatype, and would allow the repository to receive these results through the appropriate API calls, which would append the appropriate "obs.numeric_modifier" to the obs row. The API would also have to present a structured numeric result properly for rendering purposes.

Complex Obs Support

Assigned to: Ben Wolfe and Brian McKown

Abstract: OpenMRS has been very successful at collecting discrete coded observations; however, we also need to be able to handle narrative reports, medical images, genetic sequences and other similar documents. Our data model addresses this issue with the complex_obs and mime_type tables. The API needs to be extended to support storage and retrieval of these complex observations. We envision that many text documents or XML documents could be stored in the complex_obs table directly; however, we would want to store larger or binary objects by reference — i.e., a URL or URN pointer to a resource in another database or file system. See ticket:107.

Integration of OpenMRS and DHIS v2

Mentors: Ola Titlestad/Knut Staring (DHIS) and Burke Mamlin/Paul Biondich (OpenMRS)

Assigned to: Abyot Asalefew

Abstract: OpenMRS is a system for storing patient-based electronic medical record information. The District Health Information System (DHIS) is a system for storing and reporting aggregated patient information. Both applications have significant implementations and implementer networks in sub-Saharan Africa. OpenMRS and DHIS 2 share very similar modular application architecture. The aim of this project is to design and integrate OpenMRS and DHIS 2 at the application level such that the two applications interoperate and are able to readily share data and functionality both locally (single computer or LAN) or in a distributed network or Internet environment using the synchronization functionality of OpenMRS.

Integration of OpenMRS and DHIS v1.4

Mentors: Jørn Braa/Calle Hedberg

Assigned to: Anthony Muyepi

Abstract: OpenMRS is a system for storing patient-based electronic medical record information. The District Health Information System (DHIS) is a system for storing and reporting aggregated patient information. Both applications have significant implementations and implementer networks in sub-Saharan Africa. OpenMRS and DHIS 1.4 (Microsoft Access/VB) have different application architectures. The aim of this project is to integrate OpenMRS with DHIS 1.4 such that data collected in OpenMRS can be readily exported to the DHIS 1.4.

Integration of OpenMRS and the Electronic TB Register (ETR.Net)

Mentors: Paul Maree

Abstract: OpenMRS is a system for storing patient-based electronic medical record information. The Electronic TB Register (ETR.Net) is a system for storing and reporting limited TB patient information, aggregating and running defined reports for TB Control Program support. Both applications have significant implementations and implementer networks in sub-Saharan Africa. OpenMRS and ETR.Net (Microsoft Access/VB.Net) have different application architectures. The aim of this project is to integrate OpenMRS with ETR.Net such that data collected in OpenMRS can be readily exported to the ETR.Net supporting integrated HIV/ART and TB care.

XForms in OpenMRS

Mentors: Ben Wolfe

Assigned to: Daniel Kayiwa

Abstract: OpenMRS supports the XForms standard for the development and implementation of structured medical record forms. Currently, OpenMRS is tightly bound to implementation in Microsoft InfoPath which also requires Microsoft InfoPath (or a commercial application) to complete and submit the forms. The aim of this project is to extend OpenMRS to include full support for XForms including browser-based form-filling.

XForms Designer

Mentors: Eric Manders and Brian McKown

Assigned to: Carl Fourie

Project Page: XForms_Designer

Abstract: OpenMRS supports the XForms standard for the development and implementation of structured medical record forms. Currently, OpenMRS is tightly bound to implementation in Microsoft InfoPath which also requires Microsoft InfoPath (or a commercial application) to complete and submit the forms. A project is already underway to extend the functionality of OpenMRS to include full support for XForms including browser-based form-filling. The aim of this project is to develop options for designing XForms developed using an open source schema design application, such as OpenMRS. This project will cooperate closely with the XForms in OpenMRS projects.

OpenMRS Lab System Integration

Mentors: Neal Lesh

Assigned To: Richa Dwivedi

Abtract: Diagnostic lab results are essential to medical care in high-income and low-income regions alike. However, in low-income countries, lab results are often not available to clinicians during patient care, even when they have been ordered. Computerization can help with the task of tracking, storing, and accessing a large number of individual processes and results, as well as monitoring and improving the quality of lab. There are a few open source lab information systems (LIMS) available, though none has been demonstrated to meet all the needs and be appropriate for small and medium sized laboratories in low-income clinics. The objective of this project will be to define protocols and develop a module for interfacing OpenMRS with a LIMS. This will include components in OpenMRS for helping to track the status of pending lab results, produce alerts for out-of-range results, and produce notifications for urgent lab results.

Integration of OpenMRS with EpiHandy

Mentors: Jørn Klungsøyr

Assigned to: Rajesh Kashid

Abstract: OpenMRS is a system for storing patient-based electronic medical record information. EpiHandy is an open source survey design and data collection application for handheld computers. Both applications have significant implementations in sub-Saharan Africa. The central database design pattern in OpenMRS hard codes the notion of an encounter between two classes of person with a number of observations stored at each encounter. This pattern is very similar to that of a survey. OpenMRS and EpiHandy (Microsoft SQL Server/VB.Net) have different application architectures. The aim of this project is to integrate OpenMRS with EpiHandy such that the OpenMRS database can be used for routine data storage of EpiHandy survey and medical record data.

OpenMRS J2ME Application

Mentors: Simon Kelly/Neal Lesh

Abstract: The Mobile Forms collaborative has developed a pilot J2ME application that receives and displays XForms on PDAs and mobile phones. The forms are completed and data stored on the device before being uploaded to a central server. The aim of this project will be to extend the functionality of the core J2ME application.

OpenMRS Transport Layer

Mentor(s): Simon Kelly

Assigned to: Edgar Rojano Chaparro

Abtract: The Mobile Forms collaborative has developed a pilot J2ME application that receives and displays XForms on PDAs and mobile phones. The forms are completed and data stored on the device before being uploaded to a central server. The aim of this project will be to extend the functionality of the transport layer to work on a number of different devices.

Audit Module

Mentors: Brian McKown and Somebody

Assigned to:: Jinfei Shi

Abstract: Create a module that performs several audit queries on the database. It could perform checks for duplicate concept names, patients with no preferred identifier, persons with no person_name, obs with no encounter_id to name a few. It could also display the latest date_changed for some tables such as concepts and forms. See ticket:644.

Genome Data Storage and Drug Resistance Prediction

Mentor Leads: Chris Seebregts and Ben Wolfe

Assigned to: Hao Liu

Abstract: Drug resistance is an inevitable consequence of longterm antiretroviral treatment and many patients will eventually need drug resistance genotyping to determine resistance profiles and salvage regimens. While drug resistance testing is not currently done in developing countries, it is current standard of care in developed countries for patients failing treatment and, more recently as a result of significant levels of prevalence of resistant virus, for drug-naive patients beginning treatment. As costs fall and rapid methods become available, it is likely that genotyping will become increasingly common in developing countries. Genotyping is the most common way of determining a drug resistance profile and entails determining the sequence of the virus in areas targeted by drugs. Prediction algorithms are then used to predict mutation patterns and phenotype (actual behavour) from genotype. There are several different methods, including rules-based and machine learning techniques. The aim of this project will be to extend the OpenMRS data model to be able to store genetic information (probably using the document data type) and to develop a module(s) comprising prediction algorithms and a user interface to enable clinicians to view a patient profile that includes drug resistance information to make more informed decisions about patient treatment regimens.

Developer Documentation

Assigned to: Michelle Murrain

Abstract: I will be facilitating documentation for the OpenMRS project: helping the community move this process forward, facilitating documentation sprints, facilitating conversations about tools and documentation architecture, and writing documentation where appropriate. This is designed to be a deeply collaborative and facilitative role, one that builds on the strengths of the community, and helps to create organizational processes that will last over time.

Detailed Documentation Workplan

Automated "In-line" OpenMRS Web Application Updates

Mentor(s): Ben Wolfe

Assigned to: Upul Godage

Abstract: OpenMRS is a J2EE web application which operates within Tomcat or another servlet container framework. Consequently, updating versions of OpenMRS requires a number of manual steps (such as updating the .WAR file, running SQL update scripts, etc). Given the growing numbers of OpenMRS implementations that have limited technical knowhow, we would like to see functionality for OpenMRS that would allow for automated updating of the application from within the application itself.

Some ideas of how such a feature would be implemented:

• Creation of a separate daemon that existed either as a service or a seperate war which kept up with recent updates and had the ability to affect the servlet container's control of OpenMRS
• Creation of an external application that could be called by OpenMRS to do the behind-the-scenes work
• Use of rsync to allow for incremental, diff data transfers from mothership
• Configurable parameters such as: updating by nightly builds vs. major point releases, updates linked to the scheduler, etc.

Target: Successful completion of this project would at the minimum allow a end user from within OpenMRS to be notified of a new OpenMRS version, and upon administrator choice, would update the web application to the most current version. The approach should work within Tomcat at a minimum, but 10 points extra credit for other servlet container support. :)

For more information, see ticket:113.

Advanced Digital Image Viewing and Annotation

Example Image Viewer Applet

Mentor(s): Mike Seaton

Assigned to: Tor Lye

Abstract: As images (chest x-rays, photographs of rashes, etc.) are loaded into OpenMRS, we will need tools to allow users to view and manipulate these images. We would like a clinician to be able to bring up one of the images in OpenMRS and easily manipulate the image to view details and potentially annotate the image. For example, a radiologist could bring up a patient's chest x-ray, zoom in to part of the image and adjust the image contrast to diagnose tuberculosis, and then add their impression to the database — e.g., add an arrow to the image along with a comment like "this is consistent with tuberculosis."

Some ideas of how this could be implemented...

• Use open source or freely available technology to render the image (Java Applet, JavaScript, Flash, etc.)
• Provide an intuitive interface for zooming, changing window levels, edge-detection, etc.
• Allow the user to display multiple images side-by-side (e.g. baseline and followup chest X-rays for tuberculosis)

Target: Successful completion of this project would at the minimum allow an end user from within OpenMRS to select an x-ray in a patient's record, view and manipulate the x-ray (including zoom, pan, changing windows levels), and be able to add other observations that describe interpretations of the image.

Patient Note Writer

Mentor(s): Andreas Kollegger

Assigned to: Mohammad Shahiduzzaman

Abstract: Clinical data is captured at both a discrete (i.e., platelet count, patient weight) and a narrative (clinician plan of action) fashion during a patient encounter. OpenMRS has multiple facilities for recording discrete data. However, we additionally need functionality to store a rich, free text note within the system. An exciting development in web-based interfaces is the arrival of in-line text editors such as fckeditor and TinyMCE (see http://geniisoft.com/showcase.nsf/WebEditors for a *litany* of choices to choose from). We would like OpenMRS to have the ability to type and store a note as a complex observation within the web application.

Some ideas of how such a feature would be implemented:

• Use an open-source WYSIWYG editor (e.g., FCKeditor) to allow end users to enter rich text
• We would like to look for cross-browser solutions — i.e., avoid browser dependence.
• Should be designed in such a manner that it could be re-used for other situations where rich text observations are needed — e.g., to collect radiologist impressions of chest x-rays or pathology reports from the pathologist

Target: Successful completion of this project would at the minimum allow a end user from within OpenMRS to select a patient, type a document in-line with the browser, add relevant metadata, and then store that document within the patient's record. Uploaded documents should be viewable along with other observations as click-through (click on the observation and see the document).

Prepackaged OpenMRS Development Studio

Mentor(s): Philippe Ombredanne and Paul Biondich

Assigned to: Matthew Shanks

Abstract: One of our strategic goals is to make it ridiculously easy to develop for the OpenMRS community. One way to lower barriers to entry is to provide an integrated, prepackaged Eclipse-based development environment complete with a series of relevant plugins. Many of these tools already exist, but some of them are specific to OpenMRS. For example, we would like to see a plugin for Eclipse that adds a wizard to create the framework for building a module. Therefore, this project would focus upon building up, and maintaining an Eclipse distribution for OpenMRS.

We are pleased to co-mentor this project with Phillipe Ombredanne, the lead developer of EasyEclipse and the GSoC administrator for the Eclipse Foundation. Together, Philliipe and Paul will provide mentorship and guide the assignee through understanding what would enhance OpenMRS development.

Some ideas of how such a product would be implemented:

• use EasyEclipse as it's foundation to create all in one packages and installers for Mac, Windows and Linux
• select relevant available open source plugins and provide them in the all-in-one studio (Hibernate, XML editor, Java, JSP, XSD, etc)
• create OpenMRS branding images, icons, etc
• provide a new Eclipse plugin which creates a "wizard" for establishing the code foundation of a module.
• provide a new Eclipse plugin to create new sample modules based on existing sample modules code.
• provide a new Eclipse plugin with Eclipse forms to create and manage common descriptors and files used by OpenMRS,
• provide a new Eclipse plugin to integrate the OpenMRS documentation and API documentation and provide content assist and contextual access to that documentation
• integrate Eclipse cheatsheet and getting started guides to help new OpenMRS hackers to get going quickly
• pre-configure Eclipse environment for easy access to code, bug trackers and other OpenMRS services used by developers (i.e. configuration of plugins such as: preconfigured SVN locations in Subclipse, integration of Mylyn preconfigured with OpenMRS Trac, wiki plugin preconfigured to edit OpenMRS documentation, IRC plugin preconfigured to point to Openmrs IRC channels, RSS plugin preconfigured with OpenMRS RSS feeds, etc)
• provide support for simple management of OpenMRS servers and deployment of OpenMRS modules and application to a server
• Research and gets community input on other useful extensions and pre-configuration to add to the studio

Target: Successful completion of this project would at the minimum would consist of a single package that provided a development studio on a native system. This studio would have at least one Eclipse extension that provided a wizard for module creation and a wizard for new sample module project creation.

Registration Module

Mentors: Brian McKown

Assigned to: Saptarshi Purkayastha

Abstract: OpenMRS was originally designed for direct data entry where computers were in a central data center instead of in the clinics — e.g., patients come to clinic, their data are collected on paper forms, and then data from those paper forms are transcribed into OpenMRS by data assistants long after the patient left the clinic. Now, many implementations of OpenMRS are putting computers into their clinics and need the ability to register patients into the system as they arrive in clinic. One solution to this problem already exists: Partners In Health built a registration module for Rwanda to meet this need, but we need your help to refactor the module to a more generally useable registration tool for all OpenMRS implementations.

The Rwanda registration module presents a very simple page to the registration clerk. From this page, the clerk logs into the system and then can search for patients and, when necessary, add a patient to the system. A general module would need to support the use of barcode identifier cards and be able to run either connected to an OpenMRS server or in a disconnected state.

Some ideas of how such a module would be implemented:

• You would need to become familiar with the Rwanda registration module code and use this as the basis for a general registration module.
• You would then use the Implementers mailing list to gather information about patient registration workflows from clinics actively using OpenMRS in the field
• Identify and abstract features that are specific to Rwanda's implementation

Target: Successful completion of this project would at the minimum allow a end user from within OpenMRS to easily search for a patient and, if the patient is not found, create a new patient record. The module would need to support the most common registration workflows among the OpenMRS community of implementers and function in both connected and disconnected (intermittently connected or via USB key) to a central OpenMRS server.

Address Hierarchy Support

Mentors: Daniel Kayiwa

Assigned to: Sri Prasanna

Abstract: Some of our OpenMRS implementations need a way to enter patient location through a hierarchical approach — e.g., select a district from a drop-down list, then pick a village from within the district, then a location within the village. You could help them by developing a module that adds in this functionality. See ticket:169 for more details.

Some ideas for implementing this feature...

• use an external resource to store the list of possible address components in a hierarchy (e.g., XML format)
• start with providing a drop-down list for state/province and using that choice to drive a choice list for city/village
• respect the naming conventions used by different implementations for the various address components

Target: Successful completion of this project would at the minimum, enable an OpenMRS implementation to define a hierarchy of address components (e.g., states or provinces with the available option for city or village within each of those) and have these options drive the entry of addresses within the system through select lists instead of free text fields.

Move Tribe to a Person Attribute Type

Mentor(s): Ben Wolfe

Assigned to: Upul Godage

Abstract: The Patient object currently has a Tribe on it pointing at the Tribe object. This tribe attribute really should be a PersonAttribute. The work would involve writing some sql to convert everyone's database that is using it to the new setup. It would also entail going through the API and finding everywhere that tribe is referenced and removing it. (PersonAttributes are already able to be viewed/edited through the interface). A Module would then need to be created to facilitate editing of the possible tribes in the system. Read more on ticket:652 (Bonus points for finishing ticket:624 as well.)

Target: Successful completion of this project would provide an update for existing implementations that would remove patient.tribe from their database, moving values to the person_attribute table and creation of a module that would allow implementations that want to use tribe, create a person attribute for tribe and manage available list of tribes.

Boolean Concepts

Mentor(s): Ben Wolfe

Assigned to: Unassigned

Abstract: Convert the internal representation of boolean data into coded concepts. This will require a global property to identify both TRUE and FALSE concepts. All changes should be hidden behind the API. See ticket #67.

This project would require:

• Learning the OpenMRS data model
• Ability to create a SQL script to convert existing data
• Learning the OpenMRS API well enough to convert how boolean values are handled
• Comfort with Java and experience with (or willingness to learn) Hibernate

Target: Successful completion of this project would at the minimum, update the OpenMRS trunk so that boolean values are stored as coded concept and provide a database update that properly converts all data for existing implementations.

Data Synchronization Administration User Interface

Mentor(s): Maros Cunderlik and Christian Allen

Assigned to: Nzeyimana Antoine

Abstract: Data synchronization is a new OpenMRS feature allowing synchronization of data amongst a set of loosely networked servers. Such ability to exchange data is essential for operation of EMR system in rural areas where connectivity amongst sites maybe unreliable yet the need for timely centralized collection and analysis of data from remote sites exists.

Because of the distributed and disconnected nature of the sites where servers may be deployed, having a set of administration views that provide key statistics about the status of the synchronization process is critical to the local administrators. To that end, existing synchronization 'History' page needs to be changed to comprehensive sync status page where administrators can:

• see real-time status (processed records by state: i.e. failed, re-tried, committed)
• key sync statistics
• search logs, and view/edit details of individual sync items
• perform maintenance tasks such as archive sync journal, change various timeouts

Groovy Forms Module

Mentor(s): Burke Mamlin

Assigned to: Robert O'Connor

Project page: GroovyForms Module

Abstract: OpenMRS has a sophisticated data entry engine that allows administrators to define new medical concepts/questions, place them on electronic forms, and then gather data for the new concepts without any programming steps. Our existing solution depends on Microsoft's InfoPath® for both form design and data entry. While InfoPath can handle very complicated forms and has served us very well, the process of implementing new forms requires a fair amount of time and expertise. So, when new data are needed quickly, some implementations still turn to Microsoft Access® or other familiar, low-barrier systems to gather data and then they are challenged with trying to import or merge those data later. So, OpenMRS is looking for data entry alternatives. One of these alternatives could be the Groovy Form Module. The goal of this module would be to provide an agile method for creating simple/small web forms for gathering data and using the OpenMRS API to store those data.

We are picturing a workflow allowing a OpenMRS administrator to:

• Install the Groovy Forms Module
• Define a simple Groovy object, from which the module auto-generates a simple web form and Groovy controller script (a Groovy script that receives the form object when submitted)
• Be able to edit and/or apply CSS to that form through admin web pages
• Edit a Groovy script controller for the form that could access the API.
• Click on a button to export the new form as an OpenMRS module (.omod) file
• Click on a button to reset the Groovy Form module and start over

For example, an administrator would use a simple web form to write a Groovy script like this:

class MyForm {
  Patient patient
  String note
}

Then clicking a button would generate a simple web page with a patient selector and a text field along with a matching controller like:

class MyFormController {
  void onSubmit(MyForm myForm) {
    // do something with myForm here
  }
}

The administrator could then edit the web page to make the note a textarea and then edit the controller to do something like this:

class MyFormController {
  void onSubmit(MyForm myForm) {
 
    // validate form
    assert myForm.patient != null "You must select a patient"
    assert myForm.note != null && myForm.note.length() > 0 "Note cannot be empty"
 
    // Add note to the repository
    obs.createObs(
      myForm.patient,
      concept.getConcept("PATIENT NOTE"),
      new Date(),
      location.getLocation(1))
  }
 
}

Bonus points for:

• Supplementing the patient dashboard Forms tab or adding a new tab to allow users to access these new forms
• Supporting Groovy scripting within the form
• Adding AJAX capability to fields within the form
• Restricting access to these Groovy forms by role
• Development of domain specific language(s) to simplify the form creation or controller scripting for administrators
• Evolving to share lessons/features from the Groovy Forms Module with the existing form machinery within OpenMRS

Target: Successful completion of this project would at the minimum allow an OpenMRS administrator to create a web-based form along with a controller to interact with the OpenMRS API after the form is submitted with minimal Groovy scripting and then "deploy" that new form all through a web browser.

Extend OpenMRS ODA Plugin

BIRT ODA Plugin Architecture

Mentor(s): Justin Miranda

Assigned to: Kevin Peters

Abstract: In this project, a student will extend our existing BIRT Open Data Access plugin, as well as the OpenMRS Logic REST API. The ODA plugin interfaces with OpenMRS, through the Logic Service REST API to expose OpenMRS cohorts and tokens (similar to the way a JDBC driver would expose tables and columns). The main goals of the project are to improve the functionality and performance of the plugin, as well as to extend the REST API to integrate with the latest version of the Logic Service. The Logic Service REST API is also responsible for returning data, in response to queries made by the ODA plugin.

High Level Requirements:

ODA Functionality

• Should support changing from the default datatype of a token (e.g., numeric -> text so we get "Five" instead of 5)
• Allow users to search for specific tokens
• Improve user interface -- with new features added, the old one will become too crowded
• Persist/upload report design to the openmrs server automatically
• Persist data set definition on the openmrs server automatically
• Add ability to explode multi-value column (i.e. CD4 COUNT) - done within the logic server
• Add modifier support (FIRST, LAST) for each selected token
  • User should pick the tokens they want and then as a next step refine what the data set will look like by applying modifiers
• Support extra columns: getting the date of each CD4 COUNT in one column and the actual number representing the CD4 COUNT in another column, both accessed from the same token

Logic Service REST API

• Constrain concept tokens that are returned to ODA plugin by whether they actually return data (i.e concept questions, not concept answers).
• Add more token support to the logic service
• Needs to handle all methods available within the logic service API (FIRST, LAST, LESS THAN, GREATER THAN, and much much more).

Performance

• Cache tokens in BIRT for searching/filtering by tags

Deliverable: An improved ODA plugin and Logic Service REST API that can be used to define data sets and pull data (securely) from any instance of OpenMRS.

Extend Patient Matching Analyzers and Heuristics Support

Mentor(s): Shaun Grannis and Gary Teichrow

Assigned to: Nyoman Ribeka

Abstract: In order to create a comprehensive, aggregate view of an individual's clinical status, patient-specific data must be matched and aggregated across many data scattered sources with many different patient identifiers. OpenMRS has a sophisticated probabilistic patient matching module that:

• Adapts to a broad variety of patient identifiers
• Can automatically match patients across disparate data sources
• Analyzes the unique and aggregate characteristics of individual data sources
• Establishes matching parameters and thresholds tailored to the data being matched
• Allows for ad-hoc post-matching heuristics

The patient matching analytic functions are implemented in an easy-to-use Graphical User Interface (GUI), and the results of these analytic functions are persisted in a matching configuration file that guides patient matching across separate sources. The matching parameters are estimated using various analytic functions, including Expectation Maximization (EM). The GSoC intern would work closely with mentors to incorporate a improved "non-match rate estimator" into the Patient Matching EM Analyzer.

Further, after the probabilistic algorithm declares a match or non-match, the OpenMRS patient matching module allows for ad-hoc post-matching heuristics. These heuristics help to prevent false-matches in specific edge-cases such as twins or parent-child pairings. The heurisics framework is in a nascent state and we seek to implement post-processing heuristics to accept/reject potential matches, which may follow the following example:

• Define Rules (rules evaluate to True or False):

Rule  Concept1  Criteria  Concept2
----  --------  --------  --------
A.    LN.A      ==         "SMITH"  <-- Absolute Value
B.    LN.A      !=         LN.B     <-- Value Referenced by _field_
C.    YB.A      >=         "2006"   <-- Absolute Value

• Apply Rules (and combinations of rules) to each pair and assign an action (eg, reject or accept):

ID   RuleCombo  Action
---  ---------  --------
1.   A or B     Reject
2.   C          Accept

Target: Successful completion of this project would improve the accuracy of the matching results in two specific areas. First, the probabilistic parameter estimates will be improved, and second, the probabilistic output can be filtered by post-matching heuristics. To accomplish these objectives, the student will A) incorporate the "non-match rate estimator" into the Patient Matching GUI work flow, and B) Will help extend the rules (heuristics) framework in the Patient Matching module.

Getting Started Projects

A quick browse through the OpenMRS source code will tell you that its a big and scary place. Where's a good place to start? Reports in Trac can be deceptive, deceptively hard... or deceptively easy. So we've compiled a list of pointers — from the experts. There's plenty to do, and we sure could use the help. Here are some fixes that are straightforward; they just need some time and attention

Source Code Licensing

Abstract: Every java code file that OpenMRS puts out needs to be headed by the license block of text. See ticket #188 for details.

Source Code Commenting

Abstract: The source code is commented (only) occasionally. In some places, the javadoc comments are either incorrect or out of date. See ticket #143 for details. As you browse the code, it would be nice to have at least class level comments as well.

Tickets Marked as Trivial

There are tickets on Trac (our Project site) that are labeled as "trivial". These tickets are meant to describe projects that should be fairly quick and easy. Browse those and feel free to request ownership.

Roll Your Own Project

We've listed some ideas for projects here, but we're more than happy to entertain other ideas if you've got 'em. One place to look for alternative ideas would be our growing list of ideas for modules.

Modules

Abstract: The OpenMRS framework allows for modules through a module API, using Spring's AOP.

• Take a look at modules listed on the Design Plans page. Help with any of these modules would be appreciated. Similarly, if you have ideas for a new module, we would love to hear your ideas.
• We encourage module developers to save their code within our subversion repository
• Modules are delivered to implementers through the Module Repository

Other General Coding

Browse the currently open tickets. These tickets represent work needing done. Some tickets are assigned but not accepted. Post a comment asking about the status, and if the assigned user is not currently working on it they can transfer the ticket to you.

Non-Coders

Are you interested in OpenMRS and have ideas for potential projects/improvements that are not listed here? We would love to hear about them. Want to translate OpenMRS into another language? Please consider joining our implementers mailing list (from our home page) or joining our forum and adding your suggestions to the water cooler forum. Take a look at the contribution page for more details.

• This page was last modified 17:13, 20 July 2008.
• This page has been accessed 6,450 times.
• License
• About OpenMRS^®