Client libraries for the LAMP Platform

-- by Aditya Vaidyam

Our team at the Division of Digital Psychiatry develops a comprehensive digital medicine platform called the LAMP Platform (short for "Learn", "Assess", "Manage", and "Prevent" — not "Linux", "Apache", "MySQL", and "PHP" unfortunately). It's built to serve a wide array of clinical healthcare and medical research needs, but started with humble beginnings in psychiatric and neurocognitive research. Starting with the foundational goals of health equity, ethical design, security & privacy, open data, and open science, the aim of the LAMP Platform is to derive unique insights from the data of individuals with lived experiences, accessible to and for the benefit of all individuals around the world.
​
Over the last year we've worked closely with patients, study participants, our many global collaborators, and key developers to re-architect the LAMP Platform and translate our clinical goals and needs into robust engineering principles. In this post, I'll be talking specifically about how we support our principles and goals through our newly released client libraries for the LAMP Platform.

Whether it's patients in the clinic or participants in a study, we believe the individual who created the data reserves the right of ownership, though clinicians and researchers might also have access to that data, through the expressed digital consent of that individual. We strive to create tools and facilities in the LAMP Platform to allow the individual to retain agency of their data as well as to collaboratively participate in the co-creation process.

Even though the LAMP Platform provides a web interface (called the "Dashboard") to access, manage, and visualize data, it may not always be the best tool for a given situation. For example, while it's handy for clinicians to quickly generate reports to add to a patient's electronic medical record, it's not always easy or intuitive for individuals to ask and answer statistical questions about their own mental health. For more advanced needs and requirements, it's clear a graphical user interface might not make the cut. To address these concerns and many more yet to be anticipated, we also offer a unified API that we call the LAMP Protocol.

Any device or tool that "speaks" the LAMP Protocol can be thought of as a part of the wider LAMP ecosystem, and in fact, both our iOS and Android apps, as well as the Dashboard, all communicate via the LAMP Protocol. It's defined and made available as an OpenAPI specification and makes use of runtime-level JSON Schema to support new integrations and functionality. We've designed a resource-oriented data format suitable for general purpose document storage, as well as designed an integrated "event stream"-oriented format more suitable for data analysis. In the LAMP Protocol, Event Streams can be approximately understood as a continuous timestamp-indexed series of data packets, as opposed to Resources, which are uniquely-identified documents in a structured hierarchy. In addition, the LAMP Platform also supports more advanced features such as Automations, Sensor Fusion, Tags, and more, which I won't be going into detail on.

Initially, we attempted to rely on our OpenAPI specification and generate client libraries in a language of choice as each of us needed them but we quickly realized that it led to a number of inconsistencies and versioning issues that made sharing code with our collaborators difficult. Because we recognized our primary audience (our own team included) had proficiency in the Python, R, or JavaScript programming languages, we decided to focus our attention to fine-tuning those libraries instead. Furthermore, we're starting to integrate some of our own internal transformations and workflows into these libraries, including integration with other amazing libraries like React in JavaScript, pandas in Python, or data.table in R. As a result of our efforts, it's now possible to interface with the LAMP Platform in these languages with just three lines of code: package installation, library import, and server authentication.

It doesn't end there, however, as in the coming weeks we'll be adding command line interface support to our JavaScript library, which will bring the vast functionality of the LAMP Dashboard to a more concise toolkit that will also allow data scientists and developers to integrate the LAMP Platform into their Notebooks and workflows and effortlessly deploy visualizations for medical research or Automations for clinical decision support. We'll also be adding curated Swift and Kotlin libraries once they're ready, allowing any developer to design, architect, and deploy native apps that integrate tightly with the LAMP Platform.

It's with these tools and libraries that our patients are able to conduct unique and reproducible digital experiments to learn more about their own mental health. While working from home, a patient-collaborator decided to test the question of whether changes in indoor air quality affected the number of auditory hallucinations they experienced throughout the span of a week, integrating the LAMP Platform with the Nordic Thingy sensor prototyping kit. Even though they determined that there was no statistical correlation between the two variables, it wouldn't have been trivial to conduct a personalized scientific experiment like this one without the agency of data upheld by the LAMP Platform or the flexibility afforded by its Python client library.
​
At the Division of Digital Psychiatry, we understand the importance of fostering an open source community and ecosystem, so we'd like to invite you to join us for a chat in the LAMP Community, check out our projects and contribute at GitHub, and learn more about what the LAMP Platform can do or how it works. Whether you're a curious developer, interested researcher, or simply an individual who believes in open source, we hope you'll appreciate the LAMP Platform.