Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Functional Requirements

Actor Goal List



Data Manager (Eldoret)

  • Propose new clinical content (forms + concepts)
  • Edit and re-propose rejected clinical content
  • Proposed changes to existing approved content
  • Be notified of proposed clinical content lifecycle changes (ie. submitted by me). For example,
    • Under consideration
    • Rejected
    • In production
    • Approved - waiting for publishing to prod
    • Needs editing (with comments attached)
    • etc
  • View all proposed clinical content
  • Send proposed clinical content to Indianapolis OpenMRS Dev instance

Data Manager (Indianapolis)

  • Prevent content updates on Eldoret OpenMRS Dev instance during a certain timeframe
  • View all proposed content by:
    • Not viewed by me yet (new)
    • Under review (waiting for an Indianapolis Data Manager to take some action)
    • Approved - waiting for publishing
    • In production
    • Retired
    • Rejected
    • Awaiting re-submission
  • Change the lifecyle status of clinical content:
    • Approve content
    • Reject
    • Comment on proposed content
    • Request that the submitter updated and re-propose some content
  • Push content updates back to Eldoret OpenMRS Dev Instance
  • Push content approvals to Eldoret OpenMRS Prod Instance
  • Receive email/message notifications of all new proposed content and lifecycle status changes.


Gliffy Diagram
nameAMPATH Content Management Deployment Architecture


  1. Assumed that the same module will be deployed to all 3 instances of OpenMRS


  1. Concepts should not be modified. Editing and modifying a concept changes the context in which previous clinical data was captured. A concept that needs updating should be published as a new version with a reference to a retired previous version.
  2. Synchronizing concepts based on ID versus GUID. If this is done based on a simple auto-increment integer primary key then there will be collisions.