This project is assigned to the OpenMRS 1.9 release milestone


OpenMRS has an explicit API which has not been cleanly or explicitly exposed through web services.  We have a REST module and SOAP-based module(s) where folks have done work in the area.  We need a clear and explicit strategy for supporting web services.


A single OpenMRS module to support the core web service needs.

Heavyweight vs. lightweight objects? This is similar to's approach. We could consider small & big versions objects OR consider having a standard object with the option to list additive properties (e.g., custom object).

Based on Canada's experience with WS, Returning a "summary" of objects in a list may lead to a chatty interaction.

Look at Google Charts.

Consider that we may want to support both publish & subscribe – i.e., OpenMRS may

Some notes here:

SOAP Style

Encounter DTO


Do we want to use DTOs at the API level?

Changes to the API


// something like this:
ws.getPatient(123) // default
ws.getPatient(123, [includeProperties: ["preferredName", "birthdate", "gender"]])
//we should support something like this
ws.addPersonName([patientId: 123, given: "Darius", family: "Jazayeri" ]);

// this will not work
def p = ws.getPatient(123)
p.names << ?[given: "Darius", family: "Jazayeri"]

Action Plan

  1. Web services will be developed as an augmentation to the existing API... that is, we will not rewrite the current API and then expose them as web services... we will write the web services as an independent activity, hoping that they inform the further maintenance and redevelopment of the existing API.
  2. We will use CXF as the framework.
    1. See ?Webservices.cxf Module

Assigned Developer(s)

?Saptarshi Purkayastha

Interested Parties and Mentors

?Ben Wolfe (mentor)

See Also