How to build cloud services for an IoMT company

LifeCuff Technologies delivers a new approach to healing diabetic wounds, based on addressing damage from deficient blood flow (ischemia), a significant cause of chronic diabetic ulcers.

LifeCuff Technologies is a member of the HealthTech Networking Club and winner of the Startup of September Award for the pitch of their medical device. They met bene : studio through the Networking Club and will continue the relationship by receiving a product planning with the studio’s team of experts.

Product planning is a core service of bene : studio where clients receive tailor-made, ready-to-start project concepts.

The team at bene : studio is not only curious about improving systems and applications but loves sharing knowledge and therefore has made the findings of some of the product audits public to support the HealthTech community.

The problem that needs to be solved

HomeCuff will combine an inflatable cuff and an electronic control module, powered by alternating current or battery, which is programmed to facilitate and personalize Tissue Conditioning and communicate data wirelessly to prescribing physicians. bene : studio has created a Planning document for LifeCuff Technologies to help them improve their data transmission and to develop several front-end solutions in the future. The current way of data transmission is mostly from SD cards that are manually removed from the hardware and then manually connected to the computer.

LifeCuff Technologies want to create a cloud-based solution from where they can retrieve real-life data and check the performance of their hardware. This would be the first step for them to be able to enhance performance and have more specific data. Their patients are the older generation, 45-90, and are less likely to use modern technologies. However, they do want to have a solution for compliance and to check if the machine is used properly and constantly. So in the future, LifeCuff will want a solution for that as well. They would also like to have a front-end for physicians to see results and check patient data.

The architecture

We created the recommended architecture of the new LifeCuff services and identified 2 different user types (personas):

• LifeCuff End Users: All of them having one HomeCuff device (which is similar to the current LifeCuff sensor, with additional connectivity capabilities). Many of them (but not all) have access to desktop computers or mobile devices.
• LifeCuff Scientists: Co-workers analyzing incoming data, visualized on large dashboards.

An AWS based architecture was created to handle the requirements. Elements of the architecture:

• API Gateway: Safe and secure network connection for incoming sensor data.
• Lambda: On-demand computing service to shape and store incoming data.
• DocumentDB: JSON-based document database (MongoDB compatible) to store the incoming data.
• EC2: Two different servers to handle the different needs of End Users and Scientists.

Note: these services are managed, it means that the usual functionalities (backups, logs, monitoring, etc…) are included and not mentioned in the diagram.

The development plan

We created a development plan which follows agile principles: fast release, creating additional value at each step, and using feedback from previous steps

Stage 1

After this stage, the architecture is initialized, and can be used for demonstration and hardware development.

Developed features:

• Initializing AWS architecture: API Gateway, Lambda, and DocumentDB. 
• Creating a small Uploader application (web, Mac, or Windows). It will read the current SD card content and upload through the API Gateway.
• Creating a very basic dashboard (through EC2 or other BI service) to check the uploaded data for Scientists.

Benefits of the stage:

• Can be started without any prior requirement (no need for hardware connectivity).
• Provides the requirement and test for hardware development (to be able to upload through API Gateway similar to the Uploader application).
• Provides requirements and use cases for dashboard content.
• Can be used for demonstration purposes, early feedback can be collected from the demonstrations.

Stage 2

After this stage the solution can be used by real users, with real data. The upload is still from the SD card with Uploader.

Developed features:

• Ensure compliance (HIPAA) of the architecture.
• Create detailed dashboard service through EC2 for Scientists.
• Create custom data access for Scientists.

Benefits of the stage:

• This stage can be called the MVP, since it can be released and the real End User data can be stored in the cloud. 
• The data is still uploaded manually from SD cards, but there is no need to store them on local computers.
• Extensive use of the new dashboard, with the possibility to reach the raw data.

Stage 3

At the end of this stage we recommend that the hardware connection is ready. After this stage the product is real time, the mobile and web app can be used by End Users. 

Developed features:

• Desktop (web) and mobile app for End Users.
• Real-time functionalities: Email, SMS, and push notifications based on real-time data.
• Dashboard improvements based on feedback.

Benefits:

• End Users can feel significant improvements in user experience. 
• End User engagement is improved, notifications will help to follow the therapy as necessary.
• Dashboard can be used by Scientists for almost all use cases. 
• Strong base to scale up.

Further aspects to consider

Some aspects of the development can arise during the design phase. These are collected in this section:

• Hardware connectivity: From the cloud service side, it is important that the data is coming as an https request. The solution should provide a way to handle the https connection, including the validation of the https certificate. An easier solution could be a Bluetooth connection to a mobile device, but perhaps it is more professional to include a WiFi connection directly on the hardware.
• Hardware security: Needs to be addressed, including unattended firmware upgrades, and other best practices.
• Connected hardware can receive data from the cloud, not just send it. This can open up other applications, like notifications on the hardware level.
• Data lifecycle (archiving, deleting, etc…) might need further requirements to be investigated.
• The designed architecture is based on AWS services. Similar architecture is possible on the biggest cloud providers. Further investigation is necessary if another provider is needed.
• SD card content (log) data structure needs to be clarified for Uploader app.

About product planning

bene : studio helps clients develop their product strategy starting with a product audit. With the experience of more than 100 projects bene : studio lists the values of a product and key areas to improve within the application, software, UX, design or user flow.

The audit is followed by planning where the client receives a detailed document on how the improvements can be implemented as a part of the digital product strategy.

If your startup or enterprise is interested in product audit or product planning book a consultation with us.