System design for an OpenMRS server and Android implementation

Tags: #<Tag:0x00007fe2e17601a8>

Brief introduction

Hello everybody! I am a telecommunication engineering student and I’m currently working in a project called Blood Pressure Under Pressure. It consists in an implementation of OpenMRS and OpenMRS Android Client for hypertension detection and prevention in remote areas with little or null signal coverage. Here you can check the project website: http://bpup.eu/

Currently, the system works following this schema:

The tensiometer sends data via bluetooth and the Android app keeps all the patient data. Once appears signal, the app sends all the data to the OpenMRS server.

System Design (So far…)

Pros

  • The app, is a modification from the official OpenMRS Android Client release v2.6.1. So basic functionalities are already implemented.

Cons

  • Android app is based on the OpenMRS Android Client. That means that we just took the official Android Client at some point ( release 2.6.1) and started to make modifications on the current version of the app, which now is an old version.

  • In the app we “just” need the following features:

    • Bluetooth communication between the Android device and the tensiometer
    • Forms management.
    • Database for patients.
    • Communication with OpenMRS instances using REST.

But the old-modified official client offers a lot of “unnecessary features” that we don’t really need and only make the code more complicated.

  • We have to care about small (or not that small) issues (here can be checked) of the app already solved in more recent versions of the Official Client.

Current Situation

At that time, we have achieved what we could say is the “MVP” (Minimum Value Product). The app accomplish the most basic requirements that it should have, which are:

  • Administration of patients database.
  • Form management.
  • Bluetooth communication with the tensiometer.
  • Basic implementation of the treatment algorithm.
  • Working offline.
  • Ability to dump the information to the server once there is a signal.

But still there are a lot of features to be implemented as well as the optimization and the fluency of the app (Which I have seen that both optimization and fluency have been achieved in latest releases of the app).

So the point is, knowing all the above before, shouldn’t I make an app from scratch where it only does what it really need to do? Ergo, build an app from scratch that ONLY and ONLY does this:

  • Bluetooth communication between the Android device and the tensiometer.
  • Forms management.
  • Database for patients and forms.
  • Communication with OpenMRS instances using REST.

And this is not all. Why should the app have OpenMRS “inside”? Shouldn’t I build an API on the server side capable of communicate with an OpenMRS instance?

And last, but not least, which language should I use for building the app? Could be useful to use the same language in the client and the server?

Here it goes a schema to summarize what the Alternative System “should be”:

Which way should I choose?

  1. Keep going with the old-modified official client and try to solve all the issues at the same time we keep adding features.

  2. Keep working modifying the official client but use the latest version.

  3. Build a new app from scratch capable of doing the same.

Which one would you prefer?

I am unsure yet :sweat_smile:, that’s why I posted my doubt. I was hopping that someone with experience could advice me.

PS: If the post is in the wrong place, or it is not appropriate or whatever, just told me and I will remove/edit it. No problem :+1:t2:

1 Like

@sergiogimenezi think here you are being helped to develop confidence in choice.