Metadata Sharing Project (round 2)

Primary mentor

@raff

Backup mentor

@Darius Jazayeri

Assigned to

@Piotr Bryk

Presentation

Final presentation showing all features implemented during Google Summer of Code 2011

Background

OpenMRS is a highly-configurable system, with lots of generic functionality. The advantage of this is that it's a very powerful and flexible system, but it does have a cost too: using OpenMRS requires defining a large quantity of metadata. After installing OpenMRS, a system administrator will typically have to create Locations (e.g. "Harborview Hospital"), Encounter Types (e.g. "Outpatient Consultation"), and even concepts (e.g. "Weight" and "Hematocrit").

Some of this metadata truly needs to be created by the administrator of the application: for example the particular list of satellite clinics that a hospital is serving are not likely to be shared by other users of the OpenMRS system. But some metadata should be shared among different OpenMRS users. For example a successful Malaria treatment program might want to share a package, consisting of an intake form, a followup form, a summary report, plus hundreds of supporting questions, answers, and calculations.

The Metadata Sharing Module, originally written during GSoC 2010 lets an administrator select a set of metadata, and it generates an export "package" of those metadata and all their dependencies as a zip file. That zip file can be manually shared with other OpenMRS users. So our hypothetical Malaria treatment program could share its metadata package with other projects interested in replicating their program.

Purpose

The goal of this project is to take the Metadata Sharing Module to the next level, workflow-wise, by allowing metadata packages to be versioned, and introducing a publish/subscribe model.

Domain Expert(s) / User(s)

  • Andy Kanter

  • Ellen Ball

Required Skills

Objectives

  1. Implement a workflow that allows metadata packages to be tagged with a version number, and make it easy to create a new version starting from an existing one.

  2. Allow an OpenMRS installation to publish packages, with:

    • Name

    • Version number

    • Publishing authority (e.g. "WHO")

    • What URL to check for updates

  3. Allow an OpenMRS installation to subscribe to a published package, either by uploading a zip file or entering a URL.

Deliverables

  1. Package subscription - being able to subscribe to the given URL, check for updates and import a package from this URL 

  2. Package publishing - being able to publish a package so that it can be imported through the Internet to remote OpenMRS installations 

  3. Creation of versioned packages - being able to create new versions of packages 

  4. Automatic notifications about package updates

Timeline

Project's timeline

GUI mockups

Manage Subscriptions page:
Add Subscription page:
Updating workflow: