ConnectedLife’s Healthcare AI Journey with Ocean Protocol

ConnectedLife’s AI Solution for Monitoring Parkinson Disease Patients’ Symptoms via Wearable Motion Sensors

ConnectedLife is a global All-In-One Smart-Living and Healthcare solutions provider with offices in Singapore and Germany. I am the Chief Data Scientist of ConnectedLife R&D based in Munich / Germany. At our unit, we have produced state-of-the-art technology for analyzing motor symptoms of patients with Parkinson’s disease (PD) by using motion sensor data collected from wearable devices. At ConnectedLife; we provide patients with personalized symptom monitoring, which helps in provision of optimized care. One of our major projects is an internal data repository that we could use with our reputable international clinical partners to make sharing of data transparent, trusted, and secure. We incentivize these organizations to contribute their data for research enabling 1) prevention 2) early diagnosis and 3) personalized treatment to help in the fight against conditions like PD.

The repository shall provide secure access to anonymized valuable healthcare data of PD patients that we are collecting in our clinical studies. This underpins our collaboration with Ocean Protocol, which is new but mature enough to build on to demonstrate the power of peer-to-peer data sharing using blockchain technology and smart contracts. In this article, I have briefly documented our journey with Ocean Protocol: “Ocean Protocol is an ecosystem for sharing data and services. Ocean Protocol helps to unlock data, particularly for AI. It is designed for scale and uses blockchain technology that allows data to be shared and sold in a safe, secure and transparent manner.

Ocean Protocol is “the perfect” platform for sharing healthcare data. In the medical domain, the acquisition of highly sensitive patient data from multiple clinical parties worldwide is a challenge. We believe that a blockchain environment such as Ocean Protocol can allow us to address concerns of sharing medical data with multiple parties for research collaboration, which is generally the main bottleneck for advancing AI technologies in healthcare.

Ocean Protocol’s blockchain-powered data sharing platform minimizes risks and removes frictions, enabling the safe sharing of sensitive data collected from patients and customers. Hence, as ConnectedLife, we would like to be the very early-adopters of their technology. As Ocean Protocol is still in development phase, we felt the need to evaluate the maturity of the Ocean platform in order to determine whether it is suitable for our use case.

ConnectedLife is a global All-In-One Smart-Living & Healthcare solutions provider from Singapore / Germany

For that reason, we have invited Armagan Amcalar, who is the Head of Software Engineering at Unu GmbH and the creator of several open-source Javascript frameworks such as TartJS (MVC), CoteJS (Microservices) and EsteJS (Hybrid Apps), as an external reviewer of Ocean. Armagan is one of the most well-known experts in Javascript, especially when it comes to Microservices. He is a regular speaker at many reputable developer conferences worldwide. Note that ConnectedLife had examined Ocean’s Python stack as that’s the primary stack of our R&D center in Munich.

Armagan performed a thorough review of the open source software that enables the Ocean Network, including libraries developed by Ocean Protocol. The goal of his review was to evaluate criteria like ease of use and establish a general sense of confidence. His review was conducted from the perspective of a backend engineer, one with at least 5 years of experience in enterprise-grade systems but a very limited working knowledge of blockchain technologies, especially with smart contract development. The engineer is tasked to understand and integrate Ocean Protocol into the backend services.

The concluding remark of Armagan’s inspection over Ocean Protocol’s repositories was as follows: “Given the relatively young age of the project and the size of the current team, the achievements so far are almost unbelievable. Their attention to detail in the foundational documents already shows how serious the stakeholders are about Ocean Protocol. However, to satisfy the requirements of an enterprise operating on the Ocean network, significantly more integrations required to be designed and built for the existing software solutions, including but not limited to on-premise software solutions, due to regulatory and compliance requirements. This could potentially mean tapping into the existing enterprise infrastructure, which wouldn’t necessarily be able to run greenfield open-source software applications from 2019 right away”.

Ocean Protocol is a solid effort by an expert team. Although the oldest repository is still younger than a year, massive work has already been undertaken in documenting a large amount of details and aspects of the protocol and how to interact with it. Information about various core concepts in the ecosystem, theoretical background on the inner workings of the network, governance of the network, as well as its software development efforts have been laid out extensively. Their blogs are very up-to-date, including many articles directly or indirectly related to the protocol.

This creates a welcoming environment and signals the presence of a very dedicated team. Yet, as Ocean Protocol is a protocol for others to adopt, we believe that the documentation page would benefit from extended use cases, further explaining “how” one can make use of the Ocean Protocol in their endeavors and “why” enterprises can benefit from it. Full-featured projects , which are replicas of such existing use cases, can form the basis of reference implementations for other parties.

Ocean Protocol Enhancement Proposals (OEPs) define the overall architectural existence of Ocean Protocol with extensive documentation that covers everything from access control to high-level systems architecture, with a detailed consensus-oriented specification system, promising a very solid foundation and provides a clear idea on how the platform is governed.

The open pull requests at the time of writing is a very good example of a healthy and thoughtful collaboration. The authors take time to discuss proposals extensively from various perspectives and refine them before accepting them. This shows a structured approach to concept development and instill great confidence in the future of the platform. It’s open and clear that no arbitrary or impulsive decision is taken. With the promotion of the current Raw core OEPs like 7/DID and future OEPs like 6/CSAPI or 12/EXEC to Draft phase, the Ocean ecosystem will attain a much more sound and stable structure. However, one caveat with this scale of operation is succinctness.

While the governing bodies bode well with extensive written documentation, third-party developers could benefit from more concise explanations presented in a simpler format. Although several OEPs use diagrams and illustrations to convey the structure of a certain systems, they are all stored as binary images and come from different source applications with differing styles. An improvement to the current OEP format would be version-controlled graphics using e.g. PlantUML in the current workflow to to control, change, reuse and publish diagrams/illustrations that are consistent in style.

Barge is the entry to the whole Ocean ecosystem. It is very well thought-out and architected, providing a single entry that can run on any modern developer machine to create and operate a complete ecosystem. The README lays out a plethora of options that barge can be configured in, which are extremely useful in certain situations and configurations. The repository follows an industry standard pattern of having various docker-compose files and a single bash script to combine and run them in various configurations. The bash script is clean and maintainable, although it could make use of functions and other dedicated bash scripts to increase readability.

Individual docker-compose files follow a standard pattern with Compose File version 2.1. Although it is serving the purpose of repositories today, to be future-proof and to set a modern example for future integrators, docker-compose files could be upgraded to version 3. Version 3 and up brings many new features to docker-compose, making it a native part of Docker stack including Swarm. This would allow for a seamless integration into modern Swarm stacks. Although barge is great for development, further docker-compose files and Kubernetes manifests would be desirable as best-practice examples to run these repositories in production.

Aquarius is a database for tracking metadata of data assets. It’s a nifty component that builds on top of MongoDB, exposing a thin API built with Flask library. The Flask controllers are responsible for the whole execution of a flow, e.g., asset registering. This includes input sanitization, validation, business logic and rendering results. Lastly, Aquarius gives users the ability to use advanced MongoDB queries right from the REST interface. We think that the actual business logic should be extracted into another function that only deals with parameters passed locally in invocation. This would ensure a unit testing experience that is completely independent of the REST API interface.

Following this approach in the future will enable the same business logic of creating and keeping track of assets to be easily exposed to other interfaces other than REST. The Pleuston repository on the other hand, is a very modern React application architecture that is rock-solid. It’s almost as good as an independent marketplace application on its own, rather than a reference architecture and sample work for third-party marketplace applications. With Pleuston, Ocean Protocol enables third-party developers to copy and paste certain parts of the Pleuston to quickly prototype their own marketplaces.

squid-js is the JavaScript library to interact with the Ocean network, which stands out with an extensive architecture despite its early development phase. It provides certain examples that third-party developers can execute on the network. The library has a code quality score of A, which is very promising. The code coverage, currently sitting at 86%, is remarkable, given the extensive business logic. However, certain stylistic choices in the repository can be improved. On the other hand, squid-py includes Jupyter notebooks in order to provide a WYSIWYG interface to the Ocean network, offering a flexible sandbox environment for Python developers. Using these notebooks, one can easily list and search for assets in a Metadata store, list users associated by an account, create metadata and service-agreements for assets, and finally get and sign service agreements for assets to purchase them.

A Complete Ecosystem of Healthcare Enterprises Sharing Incentivized Data Securely via Ocean Protocol

After our technical investigation, we have concluded that the above described components (Pleuston, Brizo, Aquarius) of Ocean Protocol’s stack are perfectly sufficient and can be leveraged to build a “trustless” environment between several health data providers and consumers to share data for a specific purpose. Ocean Protocol is enabling this use-case through smart contracts, as well as immutable proof of transactions, which sets the cornerstone for building a data provenance trail.

At a later stage, we believe that Ocean Protocol can provide the infrastructure to include distributed computing such that data stays in situ and compute goes to the data. To sum up, as an open-source technology (also stemming from the fact that there is not yet production deployment of the network), the Ocean ecosystem is still in alpha development but it is clear that the Foundation commits a huge amount of effort to get it ready for enterprises.

As it stands now, the team, with their solid approach to development, would relatively easily meet the requirements of a scale of efforts, especially with incoming third-party OSS developers. The amount and quality of work achieved in this short duration gives us a very positive outlook. At the same time, the current complexity of the ecosystem isn’t particularly easy for new 3rd-party developers. More support structures, in terms of FAQ, knowledge bases, guides and use-case implementation examples, and more structured support ticketing systems would be required to enable enterprise integration.

Having said that, activities on the current Gitter chat and the dedication from Ocean’s team members is very positive. If the team can bring their expertise of laying out foundational blocks and converting ideas into written form into more structured support, bug fixing and third-party integration building, we believe that the Ocean will be a highly attractive environment for enterprises.