Trace: Home » documents » documents:development » guidelines

Development Guidelines - The Big Picture

This document exists to guide the development of devices suitable for use in developing countries where infrastructure may be limited and the operating environment demanding. These ideas serve as both guidelines and goals for device design.

This document is evolving, and we invite the thoughts and ideas of others involved in the project.

Core Values

  • Freedom and sharing of information.
  • Openness of design, methodology and communication.
  • Justice and ethical project management.
  • Community focused development.
  • Accessibility to contribute independent of background, training or nationality.
  • Empowerment of those involved in the project or using project devices.

Device Function

  • Simplicity of function – individual devices should perform one function well and only one function. (eg. deliver PNS pulse patterns; measure oxygen saturation; display ECG & HR). Multi-function systems can be achieved through the use of multiple, interconnected, single-function devices, not by a single multi-function device. This reduces the number of single fail-points that can bring down the whole system, improves reliability and increases extensibility.
  • Feature creep should be avoided. Additional device features should be added only when they can be demonstrated to have a significant clinical impact or a minimal cost in terms of complexity, economics and usability.
  • Safety & accuracy – devices should only be released as ‘production-ready’ designs when they are demonstratably safe and reliable.

Device Hardware

  • Standalone devices – each device should function independently of other devices, although it’s function may be enhanced by being connected to another. Eg. the jfish pulse oximeter will function as an isolated monitor, but by connecting with a jfish ECG, the ability of the pulse ox to correct for movement artifact is enhanced.
  • Battery powered, making effort to use the most commonly available cell types, such as ‘AA’ cells.
  • Low power consumption
  • Component minimisation
  • Component standardisation
  • Microcontroller choice – where possible all devices should standardise on a single microcontroller platform (ie. Atmel AVR) and if appropriate, a single microcontroller model (eg. AVMega64).
  • Device networking – all devices (where relevant) should have the ability to communicate with other jfish devices (or a computer) using a standard protocol. The ability to be networked is a secondary function and need not be finalised for a device to reach ‘production-ready’ status, but provision should be made in the hardware design so this is achievable by a firmware update alone. The (as yet undefined) networking guidelines will be here.
  • Consumables – where possible we need to produce instructions for the community-manufacture of consumable equipment (eg. ECG electrodes).

Device Software/Firmware

  • Coding where possible should use medium and high-level languages, such as C, as opposed to assembler.
  • Documentation should be written as devices are developed and firmware coded, not only after a device is finished.
  • Code commenting should be in English to help interaction within the community. While the project tries to avoid an Anglo-saxon bias, only one language should be used for code comments, and English has established itself as the most universal IT language to date.
  • Maintainability and code reuse should be given a high priority to help avoid duplication of effort.

Device User Interface

  • Simple – the UI should be as simple as possible, without impacting on usability or function. Functions of the device should be accessible with minimal amounts of user interactivity (ie. not hidden underneath multiple menu levels).
  • Self documenting – recognising that the devices are to be used by people from a variety of cultural and linguistic backgrounds, the UI should be as self explaining and language-independent as possible.
  • Consistent – the user interface should be consistent between devices allowing time already invested in using one device to be easily translated to another.
  • Distinct – the function of each individual device should clear and obvious.
  • Uncluttered – information (eg. heart rate, oxygen saturation) should be presented to the user in a clear way, uncluttered by unneeded or less important information.

Development Tools

  • Free Software/Open source tools should be used whenever possible in the development toolchain and the maintenance of the project. The use of free tools improves accessibility for those with limited resources.

Intellectual Property and Attribution

  • Copyright of documentation, code and designs are retained by the original contributor, but are automatically licensed under the apropriate open source license, and in doing so grant the project access to the IP under the conditions of the license. Please clearly identify your contributions.
  • All production devices should be clearly marked with reference to the project website allowing a end-user to easily access project documents and to help acknowledge the work of contributors. is powered by the excellent Dokuwiki. Hosting, server, OS and design credits.
This work is licensed under a Creative Commons License.

Creative Commons License