Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Projects

Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0
Warning
titleOutdated

The project described here has not had any usable work done on it, largely because the use cases described are too complex.

We are going to try a simpler approach to building a Concept Proposal module, that can be successfully completed, and we can then iterate on further.

See Concept Proposal Client and Server.

Artifacts

  1. Concept Proposal Module Requirements
  2. Concept Proposal Module Documentation

Background

At the heart of every OpenMRS implementation is a concept dictionary that defines the medical concepts (questions and answers) used as the building blocks for forms, orders, clinical summaries, reports (almost every aspect of the data). Most OpenMRS implementations have an open concept dictionary - one that is considered incomplete and evolves over time. Therefore, as clinicians document conditions the concept dictionary inside OpenMRS must be expanded to accommodate them to support meaningful clinical documentation.

Currently, there is a simple mechanism inside OpenMRS to support free text "proposed concepts". That is, a data entry clerk can create a proposed concept for an idea that hasn't been expressed inside the concept dictionary to date. The site administrator can then view the proposed concept and process it (e.g. approve and create a new concept, or map it to can existing concept).

Solution

It is clear that the concept proposal functionality needs enhancement: First, the concept proposal needs have the capability to support the richness of information that one finds in a full concept class - coded values, numeric limits and reference ranges, etc. Second, there is need for a concept proposal lifecycle with features to support management of concept proposals (e.g. notifications to concept dictionary maintainers and site admins, and communication back to the submitter).

This project includes documenting detailed requirements and creating an OpenMRS Module to fulfill these enhancements.

Scope

Five incremental releases of an OpenMRS Module. Each iteration will include:

  1. Detailed Requirements
  2. A packaged OpenMRS Module for download: Concept Proposal Management meeting the requirements
    1. Source code conforming to OpenMRS Community Coding Conventions
    2. Javadoc
    3. Unit tests
  3. User Guide / Help files

Development History

  • 24 May 2010 to 16 Aug 2010 - GSOC 2010 student Firzhan Naqesh
  • 9 Dec 2010 to Present - AMPATH