Wiki Spaces


Get Help from Others

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


Page tree
Skip to end of metadata
Go to start of metadata
Primary MentorJan Flowers
Backup MentorPascal Brandt
GSoC StudentShekharreddy Mittapelly
Interested PeopleDarius Jazayeri, Burke Mamlin


Hack the Atlas in the right direction.


The exact scope of work is yet to be defined, but here are a few initial ideas:

  • Rewrite the atlas server backend as a node.js app presenting a simple Restful API.

  • Authentication against OpenMRS ID.
  • Add functionality to support arbitrary metric from clients.

Suggest timeline

Link to Doc


  1. Atlas Module
  2. Atlas Module 2.0 Project (all see the comments here)
  3. Atlas Module Confluence Search
  4. JIRA Project Dashboard 
  5. Project Page (GSoC 2011)
  6. Project Page (GSoC 2014)
  7. Altas Docker (WIP)

Source Code

  1. openmrs-contrib-atlas (PHP Laravel Framework)

  2. openmrs-contrib-atlas-node (Node app on the server side)
  3. atlas-mock-id ( multipass mock auth written by Alexis)

Related Talk threads

  1. GSoC-2016

Atlas 3.0 Documentation

  1. Atlas 3.0 Docs



  1. Pascal Brandt Darius Jazayeri I'm surprised that 'Rewrite the server code in a modern framework that is not PHP' is optional as this point. I believe that in the Dev/Design meeting with Bahmni, it was decided that rewriting this in Node.js would be a good GSoC project on it's own.

    1. Shreyans Sheth, the idea is that whoever is going to pick up this project can help define how exactly it is shaped. We don't want to rewrite the code for its own sake, without also providing some business value. So a project proposal should suggest a set of new features and possibly technical changes to support them.

  2. This project is entitled "Atlas Module Enhancements," but the work describes enhancements to the Atlas server, not the module.

    I too do not think we should invest any more in the PHP Laravel Framework. It's a niche technology not commonly known by the folks trying to enhance or support the Atlas service. Our goal for the Atlas was to convert to a Nodejs application deployed via Docker. Any work done in PHP would either need to be completely re-written or abandoned when we migrate to Nodejs.

    FYI – the Atlas Server (openmrs-contrib-atlas) was designed to be a RESTful backend and a JavaScript client backend – i.e., the server is concerned only with providing a RESTful API + Authentication and the JavaScript frontend uses Google Map API to do all of the UI. Available technologies have changed dramatically since we began the Atlas and we've also gained a lot more experience creating truly RESTful APIs.

    I would suggest:

    • Re-write the Atlas Server backend as a Nodejs app presenting a simple RESTful API (with support for the legacy "ping.php" endpoint to receive data from older versions of the module). Endpoints can be added to support the reporting enhancements. For example:
      • GET /markers
      • GET /markers?types=:types&versions=:versions&dists=:dists
      • GET /marker/:id
      • POST /marker/:id
    • Re-write the Atlas Server frontend as an Angular app.
    • Develop & deploy the apps using Docker for easier future development & maintenance.
    • Release a new version of the Atlas Module that submits data to the new REST resource.