The LAMP server encompasses two main purposes:
- communicate via the LAMP protocol as an API to any participating clients, and
- store data in the LAMP protocol data format.
As the client of the LAMP server need not worry about the data storage, the semantics of how the data is stored as well as where, or for how long, are transparent and are subject to change in real-time. As long as the client uses the API, all storage access is transparently cached, proxied, or retrieved from a pre-specified medium.
We'll use in context the examples of Patient A, in metro Boston with an LTE-connected (high speed cellular data) Apple iPhone 6S+ and an Apple Watch, and Patient B, in rural India with a Xiaomi Redmi GO Android phone and limited spotty cellular data. While both are patients with mental health needs, the differences in their environments and in their devices could impact the quality and availability of the features LAMP is able to provide. While Patient A sometimes may not be able to charge their devices or access the Internet, Patient B, as well as his or her clinicians, face significantly larger barriers. Patient A is able to access a number of WiFi hotspots and subsidized cellular data, where Patient B may not have access to WiFi at all, with only limited cellular data coverage to rely on. Suppose a hypothetical situation in which both Patient A and Patient B begin to report increased psychotic symptoms, depressive mood, decreased physical activity, and increased suicidality. A typical app requiring both constant network connection and high frequency sensor data collection to deliver an intervention could respond to Patient A's changes adequately. There is a tremendous chance that it might not, however, respond to Patient B and deliver the correct intervention on time, due to Patient B's environment; even the slight likelihood of such an occurrence would not be considered acceptable if using the LAMP platform. The proxy mode feature developed core to the LAMP platform allows us to achieve an isolation between factors external to the app, WiFi or cellular data for example, and operating requirements internal to the app. This means that the app will work the same way and deliver the correct interventions on time for both Patient A and Patient B.
In proxy mode, an instance of the LAMP server can continue to vend the API without being attached to permanent/long-term storage. This process requires:
- a data cache,
- a connection to another instance of the LAMP server, and
- periodic synchronization between (1) and (2) determined by an availability factor.
The proxy mode use-case of the LAMP server enables chaining instances together for accumulative data transfer. This serves useful for several reasons:
- network availability no longer impacts the API client as long as sufficient storage space is available for caching.
- ActivitySpec updates (that is, when the code underlying a cognitive test or intervention, for example, is updated) are automatically propogated to all instances downstream of the first non-proxy instance when synchronization occurs.
- thus, an "application update" not involving the native code of the API client occurs transparently.
- connectivity method is not specifically defined; though it becomes the concern of the specific instance, it allows for flexibility of transfer between WiFi, bluetooth, LTE, etc. as needed or as capable by the hardware.
As battery and storage size are concerns that impact the overall cost of a smartphone as well as how often it must be charged, Patient B as well as patients with lower economic ability, for example, may not be able to sustain high frequency sensor collection while simultaneously lacking consistent network connectivity. By both lowering the collection frequency of sensors and running an app-local instance of the LAMP server configured in proxy mode, Patient B will be able to use the same app, automations, and interventions, at a lower but still acceptable fidelity while incurring less battery and storage penalty. In contrast, even in capable devices and well-equipped environments, recording high frequency sensor data from multiple devices still require coordination. Patient A would be able to configure the smartwatch instance in proxy mode to connect to the smartphone instance, which itself would be configured in proxy mode to connect to an instance of the LAMP server in the cloud. This daisy-chaining of instances allows the smartphone instance of the LAMP server to effectively "see" the data from the smartwatch instance and be able to perform actions in response to it.
The network-visible model of customizable patient interactions in the LAMP Platform is as follows.
Limitations & Strategies
While a server instance in proxy mode appears transparent to any clients, there are a few concerns followed by mitigations thereof:
- origination: data cached and transferred through several instances in proxy mode would lose meaningful tagging of origin (i.e. from a wearable with high accuracy sensors or a smartphone with low accuracy sensors).
- the use of an API key carries origination information encoded as a JWT (JSON Web Token) for all clients irrespective of which server instance they choose to communicate with.
- LAMP server instances must only brand their origination upon data if none exists already.
- timestamp invalidity: though the root instance of a LAMP server may be geolocated in the EST (U.S. East) time zone, it may be synchronizing with instances configured in proxy mode geolocated in the IST (Indian) time zone.
- LAMP server instances convert timestamps into the GMT (+0) time zone upon receipt from the client.
- upon client data access, the LAMP server re-converts timestamps into the local time zone (as specified by an IP address, for example) or the time zone requested by the client.
- automation support: intensive automations such as those written in Python or R cannot be invoked without network availability at the root instance.
- synchronization of non-timestamp-marked data: update or creation actions on non-event data cannot be synchronized or merged.
- such actions can be considered completed by the proxy mode instance but will be queued for synchronization with a timestamp; if the root instance rejects the action, the local proxy mode instance will be reconciled with the most recent data.
- Activity deployment-notification and scheduling: a push notification to deploy an Activity to a patient at the current instance (that is, not a scheduled one) may not succeed if the root instance does not synchronize with the proxy mode instance, and specifically targeting one instance may not be possible (such as the proxy mode instance running on a smartphone instead of on a wearable device, which is unsuitable for interaction).
- the API key (that is, the origination as explained above) of a suitable client can optionally be specified when pushing a notification; such notifications will remain queued at the root instance until downstream synchronization reaches the correct proxy mode instance.
- if no origination is required, the first available proxy mode instance with the applicable ActivitySpec will consume the notification and dequeue it (preventing downstream instances from knowing it was ever present).