Developers


The architectural abstractions for Open mHealth are defined as modular software units:

  • DSU: Data Storage Unit
  • DVU: Data Visualization Unit
  • DPU: Data Processing Unit

Interoperability between data units happens through the concept of a Schema ID (a URN-like colon-delimited string) which references a schema defined using the Concordia schema language. A DSU has a small specification while DVUs and DPUs are only required to publish their APIs and the Schema IDs that they can visualize or process. Both DPUs and DVUs communicate with DSUs using the DSU specification. All Open mHealth Software Units may support one or many Schema IDs.

Data Storage Units

A DSU provides a uniform way to access data though a series of API calls. The API calls that DSUs are required to implement are:

(1) Registry Read, which returns a list of Schema IDs supported by a DSU

(2) Authenticate (using OAuth 2.0), which allows end-users to authenticate with a DSU, and

(3) Read, which allows applications to read data associated with a particular Schema ID and end-user. We currently have an alpha DSU specification in use and a beta 1.0 specification in the works.

Our beta DSU specification is available here, along with the supplementary documentation.. The Open mHealth DSU specification is designed to be deliberately simple and to take into account the ongoing existence of many data stores. The goal is to make it pragmatic and simple for a data store to become adherent to the Open mHealth DSU specification.

Our approach to data integration is also deliberately simple. Data is defined in terms of a Schema ID, Schema Version and a Concordia schema bound to the ID and Version. This maps arbitrarily complex data structures onto a single identifier that may reference other identifiers already in use. The data structures themselves are represented using JSON. Schema IDs can reference extant identifiers through the use of an External ID. JSON was chosen over XML because it is concise, maps directly onto any existing XML structure, and is natively supported by JavaScript. In addition,  robust libraries exist for it in many other programming languages.

Data Processing Units

A DPU represents a unit of work to be performed on JSON data. DPUs may be chained through multiple API calls. All that is required of a DPU is that it must have a well-documented open API and that it is stateless. A DPU may be available as a library to include in an application or as a simple HTTP-based service. For information and examples of DPUs, see this developer article. It is expected that the specification on a DPU will evolve as more use cases arise. One requirement that is sure to be added to the DPU specification is that a DPU will have to specify which schema ID(s) it can operate on and which schema ID(s) the results it produces adhere to.

If you have questions or comments, please join and contribute to our developer group.

Data Visualization Units

A DVU embodies a visual representation of data for a particular Schema ID that may have been processed by a DPU, or returned from the DSU Read call. We expect that most DVUs will live in a web browser. To that end DVUs should be written using JavaScript and HTML5 techniques. A collection of DVUs can form the backbone of a complete application for clinicians to use in order assess patient or participant data. A DVU must publish its API and the Schema ID it supports. A DVU can be thought of as a library that any other Open mHealth developer can pick up and use. A developer article about DVUs can be found here.


Get Started on Github


Browse the Repository


Join the Community