Interested in Google Summer of Code 2010?
Read this page first and watch this page for updates.

Introduction

All of the projects listed below are OpenMRS improvements or feature additions requested, but not yet completed by the community. We've attempted to scope mentored projects such that they can be completed within a one to three month period of dedicated effort.

Mentors: Please use the mentored project template to build your proposal.

HTML Form Entry module enhancements

Primary mentor:	Darius Jazayeri
Backup mentor:	?
Assigned to:	?

Abstract: The HTML Form Entry module allows anyone capable of writing HTML to design a data entry form. Many hospitals and clinics use this as their primary tool for data collection.

There are a handful of features that lots of users have been clamoring for. The goal of this project is to implement the top three:

1. You should be able to enter a list of concepts into a single field (#1318)
2. Use logic or velocity expressions to show/hide sections of the form (#2087)
3. Allow forms to be split into pages

For extra credit, refactor the design of the module to update a "model" (a la MVC) between pages, and allow scripts to be run between those pages.

Target: Successful completion of this project means completing and releasing these three features.

Resources: Html Form Entry Module Webpage

---

Global Caching Support for OpenMRS Logic Service

Primary mentor:	Win Ribeka
Backup mentor:	?
Assigned to:	?

Abstract: One of the more powerful and clinically relevant uses of an electronic medical record system is to provide decision support. Doctors can easily be overwhelmed with the amount of information and decisions to be made for a patient. This becomes even more important when treating HIV, TB, and malaria in developing countries, where the vast numbers of patients needing treatment require care to be delivered by people with less training. You can help us greatly improve the OpenMRS decision support engine (the logic service) by replacing the existing simple in-memory hash table with a robust caching tool like ehcache.

Because of our limited caching ability with the logic service, results are only cached temporarily. Each time a new question is asked of the system, a new temporary cache is born and only lasts for the duration of that request. While the current solution can help a little when complex calculations re-use the same information -- e.g., the patient's age or gender -- multiple times, a more robust caching solution would allow for results to be cached across requests -- even shared between users of the system. There are many widely used cache frameworks such as ehcache and JCS which are well-suited to this task, and we propose a project to provide service-wide caching support to the OpenMRS logic service.

Target: Successful completion of this project will include replacing the existing LogicCache with a robust caching framework like ehcache and demonstration of speed improvements and other hard measurements of cache performance improvements. Good documentation and unit test coverage of this new functionality will also be important deliverables.

Resources: Logic Service Webpage

---

Boolean Concepts

Primary mentor:	Wyclif Luyima
Backup mentor:	TBD
Assigned to:	?

Abstract: One of the main purposes for OpenMRS is to collect, store, and report medical observations like "Are you a smoker?" or "Have you been treated for tuberculosis in the past?" OpenMRS Implementations will often define these as boolean questions, meaning that the questions can be answered with either "Yes" or "No". While this may work fine initially, implementations often later decide that they need to expand the possible answers to include "Unknown" or "Maybe" as a third option (for example: "Have you ever been treated for tuberculosis in the past? Yes/No/Uncertain). When data are stored internally as boolean values (true/false), then we cannot easily transition to a third or fourth option, since boolean only allows for two states. To handle more than two options, the question must be defined as a "Coded" datatype, which means that the answer(s) are stored as references to concepts (for example, see the concept for "[ http://demo.openmrs.org/openmrs/dictionary/concept.htm?conceptId=1065 Yes]" on the demo site). Currently, implementations cannot easily transition from collecting Yes/No (boolean) answers to including additional answers, because boolean data and coded data are treated differently inside the API. With your help, we can solve this problem and help many of our implementations throughout several developing countries.

The goal of this project is to make life easier for all of our OpenMRS implementations to easily transition from boolean (Yes/No) questions to coded (e.g., more options than just Yes/No) questions. This can be accomplished by adapting the internal representation of boolean data within the OpenMRS API. This will require:

• Creating a global property to identify both TRUE and FALSE concepts.
• Adapting the HL7 handler to recognize incoming boolean data and store them as coded values
• Creating an upgrade script that converts existing boolean values to coded values in the database

All changes should be hidden behind the API. See ticket #67 for more detail.

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, provide a production-ready mechanism for converting boolean concepts to coded questions and handling incoming data that may have been created prior to the change (i.e., adapting the existing HL7 handler to accept boolean data for coded questions). For example, you could make a new OpenMRS module that allows concepts to be converted as needed or you could adapt the OpenMRS trunk so that all boolean data are converted at once.

Extra credit: Help at least one implementation successfully convert one at least one of their boolean (Yes/No) questions into a question that can accommodate additional answers (we can help you identify an implementer to work with, there are many that would love to have this feature).

---

Concept Proposal Module

Primary mentor:	Glen McCallum
Backup mentor:	Andy Kanter
Assigned to:	?

Abstract: At the heart of every OpenMRS system is a concept dictionary that defines the necessary medical concepts. Since Medicine is constantly changing and the needs of any particular implementation will vary over time, the concept dictionary requires continuous support and maintenance by a trained expert. As implementations grow, their need for new concepts increases, and a single dictionary administrator can become a bottle-neck. If dictionary maintenance is compromised, it can result in duplicate or poorly defined concepts that inevitably adversely affect reports and/or patient care. The solution is to provide a way for the work of data dictionary maintenance to be distributed, while keeping one or two people in charge of final approval. This project addresses a critical (and time-consuming part) of dictionary maintenance: concept creation. You can help many of our OpenMRS implementations and make many friends among those managing local concept dictionaries by creating a module to help manage proposed new concepts.

This module would provide a formal mechanism/workflow for the creation of new concepts within the system. There would be a way for users (or possibly even external people who provide contact info) to propose a new concept for the system by completing a form. That concept proposal would then be taken through a workflow, including validation, review, and eventual acceptance. Once accepted, a new concept would be created in OpenMRS. For example, consider the following workflow:

• An expert in a particular field (not currently a user of the system) is recruited to define a concept for a new lab test and is directed to the starting page of your new Concept Proposal Module.
• The expert completes a form describing the new lab test and is led through defining all the necessary metadata for the concept, which could involved defining some additional concepts for answers that are not yet part of the concept dictionary. In certain cases (e.g., the concept datatype), the user might be allowed to answer with "I don't know."
• Once submitted, the proposal generates an e-mail to a handful of concept reviewers, including a description of the proposed concept along with quick links to review or decline the proposal.
  • When the reviewer clicks on the review link, she is taken to a web page where she can edit the proposal, making any corrections and either save those changes, or mark the concept proposal as "accepted"
  • If the proposal is declined, the expert gets a "Sorry. Thanks for playing, but we don't like your proposed concept." e-mail.
• When a concept proposal is accepted, an e-mail is generated to one or more concept administrators. They review the proposal and (preferably with quick links in the e-mail) easily send it back to the reviewer with a comment, decline the proposal, or accept the proposal.
  • If the concept dictionary administrator accepts the proposal, a new concept is created within OpenMRS and all involved parties receive a confirmation e-mail.

Another possible use case:

• A user of the system finds that a concept is missing from the dictionary, so she completes a concept proposal form to request that the concept be added.
• An e-mail is sent to concept dictionary administrators, notifying them of the new concept request.
• One of the concept dictionary administrators makes minor corrections to the proposal and then assigns it to a subject matter expert for review.
• The subject matter expert (for example, an infectious disease specialist) is notified that she has been assigned, reviews the proposal, making edits as needed, and then submits the concept for acceptance.
• The concept dictionary administrator is notified that the concept is ready for inclusion and, by clicking a link in an e-mail, is able to add the new concept to the dictionary.
• The reviews involved as well as the original user receive an e-mail stating that the proposal has been accepted.

This project would require:

• Learning the OpenMRS data model
• Learning the OpenMRS API well enough adapt or add concept proposal methods
• Comfort with Java and experience with (or willingness to learn) Hibernate and Spring

Target: Successful completion of this project would include, at a minimum, a new OpenMRS module with a concept proposal form that could be used to propose a new concept, review the proposal, and either decline or accept the proposal; accepted proposals would create a new concept in the dictionary. More specifically:

• Creation of a new OpenMRS module
• A web page form that allows concept proposals to be submitted
• The necessary API methods to manage (create, read, edit, and delete) proposed concepts
• Web page(s) to manage proposals (revise them, change their status, or generate new concepts from them)

Extra credit: The following would be nice additions to this module:

• Options for notification (e-mail, SMS, Tweet, OpenMRS alert, or some combination)
• Ability to customize the workflow
• Provide some rudimentary reports — e.g., number of outstanding proposals needing review, number of reviews completed in the last month, who has reviewed proposals and how many, etc.

---

Localization Tools

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

Abstract: Currently, only some aspects of OpenMRS support localization. These are:

• The Concept Dictionary - supports localized Concept Names
• Pre-defined pages and objects that can draw from message resource bundles (i.e. messages.properties)

This leaves a rather large gap of metadata that is able to be defined at runtime by the end-user, but which is unable to be localized. This leads to the user interface containing text such as "ADULTINITIAL" or "Drug Order", because these are the "name" values for an EncounterType and an OrderType, respectively -- in other words, while OpenMRS uses localization tools for its web application, much of the internal data that drives the system (and is not hard-coded into a web page) is not localized.

This project aims to address this gap, by making the following changes:

• Create a LocalizedString data type for use by Hibernate that serializes multiple localizations for a string into a single string (e.g., en:Hello;es:Hola;sw:Jambo).
• Adjust hibernate mapping(s) to use this new data type
• Migrate the data model such that, for example, "EncounterType.name", etc were of type "LocalizedString" rather than simply "String"

Target: Successful completion of this project would include, at a minimum, at least one string value (e.g., EncounterType.name) converted to the new LocalizedString datatype.

Extra credit: Converting additional strings in the system to LocalizedString and/or creating database functions (for MySQL, PostgreSQL, and Oracle) that implementations could use to extract the string for a particular locale within their SQL queries.

---

Metadata Import Export Module

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

Abstract: This module should build on lessons learned in the OCC, the FormImportExport Module, and the synchronization branch, to provide a mechanism for keeping multiple installations in sync with regard to metadata configuration. Potentially, this module would simply be the next generation of the FormImportExport module. Whereas the FormImportExport module only supports Forms and Concepts, this module should support any metadata (EncounterTypes, OrderTypes, Roles, etc). The general reqirements would be:

• Enable a server to be configured as a "parent" or "child" metadata server
• Services that would use the "SerializationService" to enable transmission between servers
• Support for both "over the wire" or file-based import/export (i.e. with a flash drive) - compression should be utilized to maximize network efficiency
• UI for a "parent server" to specify the metadata types that it can "export"
• UI for a "child server" to specify the metadata types it wants to "import"
• Administration tools for managing import/export errors, viewing import/export logs, etc

Target: Success would be creation of a module that meets the above abstract along with appropriate unit tests and documentation.

---

Refine OpenMRS Module Administration

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

Abstract: OpenMRS module administration gives the illusion of hot-swappable modules when, in fact, the system is effectively restarted (all modules restarted) when a module is added, removed, or restarted. This project would be to provide a complete solution for ticket:708. Ideally, OpenMRS would follow the workflow of Firefox Add-Ons — i.e., deleting, restarting, or adding OpenMRS modules would not take effect immediately; rather, they would be marked as "will take effect at next restart" and a "Restart OpenMRS" button would be added to the interface. While in this space, the current (as of 1.6) module administration interface provides two inputs for loading modules (one for adding and another for upgrading), which should be consolidated into a single input: if a module is uploaded that already exists, then a confirmation dialog should appear (with the option to no longer show that dialog ... to make developers happy).

Target: Successful completion of this project includes at the minimum:

• Intern writing code that allows module upgrade or deletion to be queued for a subsequent manual restart of the OpenMRS
• Intern creates modifications to module administration page and OpenMRS upgrade wizard page consistent with these ideas

Extra credit: Writing code to allow required modules (and optionally any other modules with available updates) to be upgraded during the OpenMRS upgrade wizard process. Super-duper-we're-your-fan-for-life extra credit if you can devise a way for (at least some) modules to be upgraded without needing a restart of the Spring context.

---

Longitudinal Data Review (Discrete Data Flowsheet) Module

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

Abstract: If you want to change the world, consider working on a project that could become one of the most-used features of OpenMRS by clinicians: patient data review. One of the simplest and most powerful ways that a clinician visualizes data is by reviewing all results in reverse chronological order. While the data visualization "widget" shows graphical depictions of specific variables (e.g., trend lines), this "Flowsheet" project is more concerned with succinctly visualizing all available data for a single patient and, therefore, is more likely to take the form of web pages that render data in tables or lists. For example, a physician may be interested in finding the most recent results for a patient's kidney function. This could involve displaying many laboratory results, including serum sodium, potassium, bicarbonate, blood urea nitrogen, and creatinine levels; blood counts; and ultrasound results. For example, these could be displayed in lists and/or tables, starting with the most recent values.

Example of how one might render flowsheet data

Some ideas of how such a feature would be implemented:

• Start with a simple reverse chronological dump of patient data (e.g., select a patient and show all existing observations in reverse chronologic order)
• Allow clicking on a result to bring up more information about that result for the current patient (e.g., clicking on a patient's weight would bring up a dialog showing more information about that specific result along with additional information about weight and, possibly, a graph of weights for the patient)
• Create a simple search box to quickly navigate to data
• Add a date range selector to filter down to data within a given date rage

See Longitudinal Data Viewer for a mockup of a possible user interface design modeled from the Kayak.com website (this project would not need to accomplish all features envisioned in the mockup; rather, you could lay the foundation for us to eventually get there).

This project would require:

• Strong HTML, CSS, and JSP, and Java skills
• Learning how to make an OpenMRS module and work within the OpenMRS web application framework
• Comfort with Java and experience with (or willingness to learn) Hibernate and Spring
• Likely working with Velocity templates and/or AJAX/JavaScript libraries

Target: Successful completion of this project would at the minimum include:

• A new OpenMRS flowsheet module for longitudinal data review
• The ability for a user to select a patient and view their data in reverse chronological order
• Clicking on results brings up a dialog with more information relevant to the result (additional details of the specific result, relevant links, graph of all values for the patient, etc.)
• The ability to search for results by name and/or filter results by date range

Extra credit: Possibilities include:

• Begin to handle complex results such as sets and complex observations
• Handle abnormal flags
• Display some data in tabular form
• Render in pages vs. long form

---

Automated "In-line" OpenMRS Web Application Updates

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

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. :)

Resources: For more information, see ticket:113.

---

Genome Data Storage and Drug Resistance Prediction

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

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.

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

---

Approximate Date Support

Primary mentor:	?
Backup mentor:	?
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.

---

Encounter Type Hierarchy

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

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. ticket:1315

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

---

Change Module Sqldiff to Use a Liquibase Changeset file

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

Abstract: Modules in openmrs currently use a sqldiff file to upgrade/add data to the openmrs database they are being installed into. This is a very simplistic, top-down, start-to-finish, changeset file. Each changeset (diff) has to be run in order and each changeset is simple sql only. Core openmrs has been using Liquibase to run its database updates since openmrs 1.5, and modules should do the same. Liquibase provides many more options than what the sqldiff.xml file provides: cross database functionality (because updates are written in xml instead of sql), if-conditions, out-of-order updates, md5 hashes to prevent changes, java class file updates if desired, etc.
There is a DatabaseUpdater class in openmrs that can run liquibase changeset xml files programmatically. For this project to complete Modules need to have an optional liquibase.xml file that gets run after the sqldiff.xml file. (we want to leave sqldiff.xml for backwards compatibility-ness).
See ticket:1474

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

---

Adding "Note" Functionality to DB / API

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

Abstract: The OpenMRS community has modeled specifications for notes within the core application. In short, this functionality will allow end-users of the system to make free text annotations to various healthcare objects within OpenMRS, such as patients, observations, and encounters. These notes will provide a flexible means of adding conversational or additional information to these fairly structured pieces of clinical information. Note support will provide a lot of opportunities for new features... some examples:

• Means to allow clinicians to add narrative context to any pre-existing measurement within the system. For example: "not sure that patient felt comfortable telling the truth when asked this question"
• Means to allow data quality managers to annotate potential errors in the system

Target: Successful completion of this project would include API-level support for notes as currently modeled, and a prototype addition to the user interface which properly utilizes this new feature. Additionally, appropriate unit test coverage and documentation will be required.

---

OpenMRS Media Viewer Enhancements for Radiology

Primary mentor:	Katherine Kuan
Backup mentor:	RJ Ryan
Assigned to:	?

Abstract: The OpenMRS Media Viewer is a Flash-based visualizer of rich content such as pictures, video, and audio. Built as a part of GSoC 2009, the media viewer is a standalone OpenMRS module and is currently used in tandem with the Moca platform to allow doctors to diagnose cases submitted to OpenMRS via Android mobile phones. (See current media viewer). This project will make significant improvements to the media viewer so that it can be used in radiology workflows. The project requirements are as follows:

• Conduct multiple usability tests with groups of doctors (contacts provided by the Moca team)
• Add support for comparing medical images side-by-side.
• Create a button that pops up a search interface which allows selection from thumbnails of all previous medical images for the patient. Selecting an image shows it side-by-side with the current image.
• Add ruler and marker tools for measuring sizes and indicating regions of interest.
• Add image annotation functionality. Annotations can be either text or marker-lines. Annotations must be saved as new observations in the viewed encounter.

Target: An enhanced media viewer that allows side-by-side viewing of medical data as well as tools for annotations.

Extra credit: If time allows:

• Add controls that emulate those of common radiology imaging software
• Improve speed of image processing functions (brightness, contrast, sharpness).

Resources: See an example of a side-by-side PACS application that is similar to the goal of this project and the Moca blog about the OpenMRS Media Viewer.

---

Bug Analytics

Primary mentor:	Diederik Van Liere
Backup mentor:	David Eaves
Assigned to:	?

Abstract: “All bugs are shallow given enough eyeballs” is one of the central tenets of open source software development. This project aims at making the ‘eyes’ smarter by creating a portfolio of algorithms and accompanying dashboard to help direct a community in focusing its resources more efficiently. We have developed algorithms that predict the probability of a bug being fixed and for determining the ideal set of developers for fixing a bug.

The general goals of this project will be to:

1. Review and, if possible, enhance the algorithms that assess the probability of bug fix based on initial bug report
2. Review and, if possible, enhance the algorithms that predict the ideal set of developers to fix bug

We need to develop and implement:

1. A plugin for Trac or JIRA that displays the predictions of these algorithms
2. Has a system for noting behavior/language the violates community norms by a specific member
3. Has a notification system when a critical patch has a low probability of being patched and when community norms have been violated by a specific member

This project would require:

• Strong Python skills for Trac or strong Java skills for JIRA
• Javascript / CSS for front-end
• Affinity with statistics

Target: Successful completion of this project consist of developing a plugin for Trac (or JIRA)

Resources: For more information see:

• Jetpack for Bugzilla to predict bug fixes
• How Shallow is a Bug? Open Source Communities as Information Repositories and Solving Software Defects

---

Move Address and Name Layout Definitions to Global Properties

Primary mentor:	?
Backup mentor:	?
Assigned to:	?

Abstract: Currently different address layout options are defined in the openmrs-servlet.xml file. The user then changes the address.layout or name.layout global property to specific which one of those they prefer to use. We need to change this so that the user can specify the entire layout within a global property. This would allow the maxiumum flexibility for end users. See ticket:306 for address layouts. A ticket has yet to be created for the (very similar) name layout change.

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

---

Billing Module

Primary mentor:	Saptarshi Purkayastha
Backup mentor:	?
Assigned to:	?

Abstract: Create a module which will allow a clerk to capture the orders from the doctor pertaining to pharmacy, diagnostic tests, in-patient admission, discharge and any other types of order. These orders are generally written on a piece of paper or case sheet which the patient carries with himself/herself. This information does not get captured in the rush of a hospital at the doctor's table. This module will allow bringing together information and create a receipt of payment for the patient, which the patient then carries to the concerned department. The Billing module consists of 4 major parts:

• Interface to create bills with orders:
• The clerk should be able to create cost master for orders:
• The clerk should be able to associate orders with a patient encounter:
• Aggregate bills for collections

Additional details can be found at Billing Module's wiki page

Target: A module that allows people to view orders from different departments associated to a patient, create receipts and collect payments

Extra credit: Additional:

• Ability to customize the workflow
• Customize the bill layout through a designer

---

Radiology Module

Primary mentor:	Saptarshi Purkayastha
Backup mentor:	?
Assigned to:	?

Abstract: Medical data coming from the radiology department consists of X-ray images, videos, DICOM over TCP/IP, PACS storage devices etc. OpenMRS installed at hospitals should be able to communicate and get data from these. OpenMRS uses the complex observation as a way to store such data, but does not provide an UI/interface to configure such devices or view such data. The project is to create a module which can communicate and store complex observations, as well as provide easy UI to configure and access the devices and outputs in the radiology department. The project aims to build upon Image viewer module or other related modules.

• Manage radiology reports for a patient
• Doctor / Nurse should be able to associate observations by tagging in radiology content
• Should be able to log radiology department's activity for a patient

Target: A module that allows managing the radiology services and observations of a patient and create a summary

Extra credit: Additional:

• Able to create an inventory management for Radiology department
• Schedule radiology scans/reports to patients

---

Module Data Removal

Mentor(s):

Ben Wolfe

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.

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

Resources: See ticket:643.

---

New OpenMRS Website Template

Primary mentor:	Ben Wolfe and Burke Mamlin
Backup mentor:	Michael Downey

Abstract: OpenMRS has adopted a new logo. It hasn't gotten widespread adoption yet mainly because the openmrs.org sites aren't using it. We would like to convert the mediawiki, phpbb, and wordpress header files to use this new logo and look. Upon request, all of the current theme/files can be given out.

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

Resources: See this forum post for Burke's mockup of the website with the new logo.

---

XForms Designer

Mentor(s):	TBD
Assigned to:	?
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.

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

---

Integrate the Ivy Build System

Mentor(s):	Ben Wolfe
Assigned to:	?

Abstract: Currently jars and libraries are included in each checked out project and module. Ivy provides a convenient solution that allows downloading jars once and reusing them within the build environment for all related projects. See ticket #1130 for more details.

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

---

Web-based Logging Controls

Mentor(s):	Ben Wolfe and Burke Mamlin
Assigned to:	?

Abstract: OpenMRS provides some rudimentary tools in the web interface for accessing logs. This project would enhance the administration web interface to improve log viewing and allow the administrator to dynamically change logging levels as well as add new logging entries on the fly within a running system. For example, someone debugging a module could jump to the web interface and add a new log entry at the DEBUG level for their module class(es) and view the output through the web interface rather than having to edit log4j configuration files, restart the web application, and search for the appropriate log files.

Target: This project has not been fully described. Ideally, specific targets should be defined that represent successful completion of the project.

---