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.
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).
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.
Five incremental releases of an OpenMRS Module. Each iteration will include: