A privacy sensitive platform that aggregates data from popular health APIs and enables us to connect with custom services. Ampersand is easily scalable and does not introduce a bias on the data collected.
What it does
The Ampersand system consists of general software architecture and a loose specification for the design and development of services. The image below shows an overview of the software architecture of the Ampersand system. Ampersand consists of aggregation and distribution services, the Eyo and Vire service used in the image are examples of services consuming data from the system. They are not part of the system directly. The data flow in the figure is from left to right; from data ingestions to data storage.
The image introduces three notions: Networks, Service Types, and Service Families.
Networks are private networks that limit accessibility from other non-essential services and general access. As an example, the Redis database is only used by the consume-authorisation Service Family, so they are placed within the Redis network. Other services can only interact with the Redis database through an API provided by the consume-authorisation service.
Service Types are services that enable specific functionalities such as ingesting data from other businesses.
Service Families are services that use the same code-base, but by using environmental parameters, are tuned to different data providers. In some cases, such as the consume-subscription family, specific code is required to handle the notification sent by data providers, because the protocol of informing for updates is not standardised.
For communication between services, Remote Procedure Calls (RPCs), are used to trigger a procedure at a remote service in the system.
Why we developed it
Whereas services and code of the Do CHANGE system were tied to the infrastructure (VM), the application logic of Ampersand is decoupled from the infrastructure management using (Kubernetes) containers. This enables us to scale up quickly and infinitely.
The responsibilities for the services are redefined and restricted to their simplest forms. This increases the number of services, but services have a considerable overlap in the code to facilitate similar functionalities. This overlap can be considered as a service template to write services consistently.