Launching global rehabilitation platform – a journey into Internet of Medical Things (IoMT)

by Tomasz Puk | Jan 04, 2020

Introduction – Developing the Internet of Medical Things (IoMT)

Our client was a UK-based consumer health technology company offering drug-free,clinically-proven rehabilitation medical devices solutions. The company was established in 2003 with an established product line of medical devices for patients suffering from such diseases as: peripheral arterial disease, chronic venous insufficiency, diabetes, osteoarthritis, and chronic obstructive pulmonary disease (COPD). These devices are used by both lay users at home also professionals in health care institutions. The company’s main product is a Stimulation Device with more than two million units sold in 13 countries worldwide, including the EU, the USA and Australia since its launch in 2005.

IoMT in Healthcare

Business Goals – IoMT in Healthcare

As a part of its long term Digital Strategy, our client decided that the next generation of its flagship Stimulation Device, should become a connected medical device with significant functional and therapeutic improvements .

The Stimulation Device, has a software medical device mobile application on both Android and iOS platforms, as well as an enterprise software medical device that together deliver the following advantages over its unconnected predecessor:

  1. Enables the patient to control the stimulation device improving patient User Experience (UX)
  2. Offers personalized therapy to end users based on their individual targets and therapy outcomes;
  3. Is designed to increase end users’ adherence to the assigned therapies resulting in improved health and wellbeing;
  4. Provides context-specific content, personalized assistance, and also direct support to help the patient to better use the device;
  5. Starts offering supplementary health services directly at home and health institutions’ environments.
  6. Sends usage data to a medical device backend system, enabling Client to better maintain and identify future device improvements based on usage patterns;

On the Digital Strategy level, this was part of a broader Client strategy to:

  1. Make a transition from manufacturing physical devices to a supplying connected, clinically-proven health solutions and services;
  2. Stay closer to its users, shorten communication channels, provide instant feedback together with support;
  3. Start offering personalized services for end users;
  4. Start collecting data about how end users interact with medical and devices;
  5. Extend the digital competencies of the organization;
  6. Validate its digital strategy with taking its first step towards its implementation.

Selecting a Design and Development Supplier

Our Client was looking for a company that would fully take responsibility for leading, developing, as well as supporting CE marking of the Software as a Medical Device (SaMD) product(s) to support their digital strategy. The supplier was supposed to lead the Software Development Life Cycle (SDLC) activities and triggering, if needed, Product Life Cycle (PLC) activities. Finally they would closely collaborate on integration with a South Korean hardware vendor that develops the Stimulation medical device.

From a regulatory/technical perspective, our Client was looking for a supplier with practical experience in developing Internet of Medical Things (IoMT) solutions on the design service, engineering, and also regulatory levels. The supplier was expected to operate under a certified Quality Management System (QMS) compliant with ISO13485:2016, ISO14971:2019, and IEC62304:2004 standards, and aligned at least with MDD, MDR and 21 CFR 820 regulations. Furthermore they would define and implement non-functional requirements derived from global security/privacy regulations and standards (such as HIPAA, GDPR, CCPA, or ISO27001:2019) in the SaMD device.

Moreover, the supplier would need to be an expert in the technologies needed to develop the solution:  Amazon Web Services (AWS) for developing the cloud backend and web portal; and native mobile applications for both iOS and Android platforms. They were expected to come up with a technology stack that would fit the bill from the medical regulations perspective. Additionally, they would have to secure flexibility and maintainability over the 10 years+ of predicted SaMD product life span. The Client planned to launch the service to a global market from day one. Consequently, the solution architecture needed to be applicable globally, with practically unlimited growth capabilities.

Pro4People was selected as a design and development partner thanks to our leading  Quality Management System, medical device projects track record and experience.

Design and Development Supplier
Internet of Medical Things Architecture
Internet of Medical Things

Product and Project Teams Collaboration

As one of the first steps, Pro4People recommended the establishment of a program management structure to deliver a system consisting of an edge medical device, mobile applications as well as a cloud backend. In addition, a support team would help client work through inevitable program challenges. Program management  coordinated the following activities:

  1. Product Life Cycle (PLC) – managing product value proposition, defining functionalities, product requirements and alignment with the client’s business and digital strategies (client).
  2. Software Development Life Cycle (SDLC) – managing development of cloud backend together with mobile applications Software-as-a-Medical-Device (SaMD) projects (Pro4People);
  3. Design and Development Edge Device – managing a new, connected version of Stimulation Device (the Korean vendor);
  4. Service Provision Team – building a brand new team that would be responsible for provisioning as well as keeping the final system (consisting of all software medical devices) operational, once they had been placed in the market (Pro4People).

Product Life Cycle (PLC)

On the PLC level, the Client appointed the following stakeholders to manage the program:

  1. Program Manager – responsible for coordinating all the projects that comprise a complete system. One of the most important roles relates to integration, resolving issues, challenging the status quo, and also simply “making things happen” in all parallel projects.
  2. Product Manager (aka Product Owner) – having a product vision, defining value proposition, working on a business model. In addition, this person was responsible for defining product and software requirements, risk analysis activities, approving or rejecting use case or system functionalities.
  3. Quality Manager – responsible for defining regulatory requirements, the alignment of both the Client’s and Pro4People’s QMS’s. Likewise, leading the certification audits of suppliers and final CE marking of all the products.
  4. Head of Industrial Design – responsible for defining, supervising and leading the industrial design decisions in all concurrent projects. As a result, a unified User Experience and User Interface aligned with corporate identity was delivered to end users.

Software Development Life Cycle(SDLC)

From the SDLC level, Pro4People appointed the following persons engaged in the communication on the program level:

  1. Project Manager – responsible for managing the SDLC project following Maturity/Agile. On the Maturity level, the expected product roadmap and features were translated into the product backlog, prepared as specifications, detailed designs, or user stories. The product management activities were additionally amplified, modified, and updated with Pro4People’s expertise and know-how from previous software medical device projects. The Project Manager coordinated the SDLC team effort estimations. Subsequently, these estimations were used to inform the product team about what could be implemented and with how much effort. As a result they were essential in the continuous discussions on the roadmap planning against set business milestones. On the Agile level, the team followed Scrum methodology, working in two-week sprints, embracing change. The team deployed versions fortnightly to demo environments for the product team to verify alignment and come back with the feedback.
  2. Business Analyst – responsible for communication with a Product Manager (aka Product Owner) as well as turning a product vision and a value proposition into functions, specifications, and dividing them into architectural software units. That role also involved documenting product and software requirements along with all the traceability information required by medical regulations. Consequently, the Business Analyst worked as the primary owner of the product vision in the software development team. He explained to the engineers what the product team wanted to achieve. Correspondingly, he also informed the product team about the implementation itself, its limitations, and delivered functionalities.
  3. UI/UX Designer – responsible for designing User Experience (UX) and User Interface (UI) for both mobile and web applications. The person worked closely with the Head of Industrial Design from the client’s organization. The UI/UX design was first aligned with the Client’s Cooperate Identity, but most importantly designed and adjusted to the demographic profiles of the system’s end users specified in the PLC Intended Purpose. Rapid prototyping tools, like InVision, were used to lower the cost of experimentation, reiteration and significantly reducing any rework when implementing the finally agreed UI/UX design. Our UI/UX Designer worked closely with our Business Analyst to design the UI/UX. As a result, medical device usage was significantly simplified and designed to improve therapeutic outcomes for end users.
  4. Quality Manager. Pro4People’s Quality Manager worked closely with the Client’s Quality Manager to decide where the processes defined in both organizations’ QMS’s should be used. This resulted in a clear definition of working standards to be followed. In effect no issues were raised during both Supplier Audit and CE marking audit from a renowned notified body. Furthermore, our Regulatory Expert, helped to define an SaMD product regulatory strategy suggesting how a system shall be divided, developed, and of course documented. This also made it less prone to regulatory risk derived from changes in SaMD software when a product is put on the market.

Integration

Software-Hardware integration was another very important area of collaboration. It required excellent communication between the Pro4People mobile Apps team and the Korean team developing the medical device. As a result, the communication technology,  API specification, translation of application use cases into API calls, implementation, integration, as well as automated and manual testing were agreed upon. Software-Hardware integration was done daily. Problems were documented in JIRA and subsequently assigned to either the mobile applications or medical device development teams for further investigation and resolution.

Setting up a Service Provision Team gained importance as the project approached the Go-Live milestone. For this reason new functions were added to the program management structure: Level Two, and Level Three support in addition to our Client’s pre-existing Service Desk for Level One support. In order to facilitate system roll-out, Pro4People provided Level Two technical support, in addition to design and development activities.
It ensured in effect, that the launched products remained available and operational by executing the following technical service operations: installation, deployment, validation, monitoring, maintenance, and finally operations management process compliant with both ISO13485 and ISO27001 standards.

Start your Medical Device Project
with Pro4People!

Contact us

Design and Development of Internet of Medical Things System

 Design and Development (D&D) activities were carried out in such a way that the Client was engaged only in technical activities which they expressed an interest in. A Product Manager is always a very busy person focusing mostly on business, marketing and sales activities. In effect the communication in D&D was centered on a business level. It involved value proposition implementation, product and software requirements, product roadmap feasibilities, function discussions, mockups of the interface, or live demos of versions released and deployed after each sprint.

The first aspect of the Design and Development was software development planning. We needed to meet requirements of the Maturity software engineering approach. In addition we had to comply to standards such as ISO13485, ISO14971, IEC62304. For this reason the Project Manager prepared planning documents using Pro4People templates. The plans covered the following elements of the Software Development Life Cycle:

  1. SDLC Software Development Plan – describing an approach to software development and maintenance.
  2. SDLC Test Strategy – outlining verification activities, test levels, acceptance criteria and a link to the product PLC Verification and Validation Strategy.
  3. SDLC Configuration Management Plan – presenting an approach to managing configuration, infrastructure, baselines, environments, identification etc.
  4. SDLC Risk Management Plan – helping to document how ISO14971-defined risk management activities are executed on the SDLC level.

Internet of Medical Things – Agile Development

On the Agile level, the planning of software development consists of product roadmap management activities, estimation of the effort behind the product roadmap, dividing the latter into incoming sprints, presenting and also reshuffling the priorities with the engagement of the product team on a weekly basis.

Obligatory documentation that is checked at the moment of the product CE marking audit or the product inspection (FDA) is one of the medical device project outcomes. As a result, the SDLC team had to plan for documentation management.The scope of the documentation proposed by Pro4People derives from the system software safety classification and other regulatory requirements. The SDLC Documentation Index helped to monitor the progress of the documentation development vs. the target scope. All the documents created within the project derive from the already existing Pro4People document templates. They were subsequently used within ins2outs documentation management system.

Architecture and Technology Stack

Developing an SaMD solution requires designing an appropriate Architecture and Technology Stack. The system must meet regulatory requirements as well as be ready for multi-site deployments across the globe. Consequently, you have to rely on a partner with robust experience in these domains. Pro4People designed an Amazon Web Services (AWS) architecture following a loosely coupled architectural pattern. This architecture was in effect better suited to medical device domain than e.g. a microservices one. It assured both horizontal and vertical scaling and made the service unlimited from the infrastructure perspective. It moreover allowed maintaining a good level of control in terms of monitoring, identification of software units, simplicity of integration, and a split into the verification/testing activities. It also did not increase complexity on the Service Provision team’s side while keeping production environments operational.

A technology stack for each SaMD product was built on robust and trustworthy technologies. The technologies met all requirements derived from supplier risk assessment. When planning an SaMD, you must consider 10-years+ perspective of the product’s presence in the market. Consequently, selecting proper technology stack is a key decision that most business stakeholders may not even be aware of. This decision will also have a significant impact on the cost of maintaining your software along the whole IT product life cycle.
For mobile apps, Pro4People selected a native application approach instead of a cross platform framework. That was because with slightly higher initial development costs it significantly lowers the risk and costs of maintaining application functionality in future. It was in addition driven by the need to fine-tune the applications to such platform-specific functions as Bluetooth communication with the medical device.

Configuration and Infrastructure Management

Configuration and infrastructure management with respect to both the development and production environments is a very important part of software development. It’s particularly true for cloud-deployed systems.  Consequently in Pro4People, it was the role of a SDLC DevOps Engineer. He was in charge of these activities on the SDLC side. Our DevOps engineer firstly configured the so-called DEV-BUILD environment, used as a production environment for SaMD products. It contained systems such as Configuration Management System, Continuous Integration, Static Source Code Analysis tools as well as other elements required by standards and regulations. In respect of infrastructure management, we used Terraform to automate the process of installing a new environment, and then deploying a new product version to that environment. Finally, we created an Operations Manual. It described how a production system shall be monitored, backed up, restored, deployed, and kept operational.

Business analysis

Business analysis was carried out by the Business Analyst role. That role defines a medical device system, translates a value proposition into features, user stories, or detailed designs. These analysis outcomes are then presented to the D&D team during the Sprint planning and subsequently implemented. Sounds simple? Well ;), easier said than done. Business Analysts used all their experience from similar Pro4People medical device projects to design service functionalities appropriately. This required continuous communication with the client’s Product Manager as well as the Head of Industrial Design.

The human-computer interaction spread from the medical device, through the Bluetooth connectivity, then via a mobile application, to finally communicate with a cloud backend. In addition to that, the Business Analyst was in charge of documenting software requirements. This included those derived from risk control measures. In order meet the regulatory and security requirements, Pro4People brought its predefined software requirement sets derived from GDPR, ISO27001, MDR and HIPAA.The system life-span had been planned for 10-years+. As a result, all of the business analysis outcomes were well documented in ins2outs system in the form of user stories, mockups, detailed designs, requirements and other business analysis outcomes. In effect we could meet all the IEC62304 requirements. Above all though, we were able to grasp and manage a system vision over its predicted life span despite any changes in the team configuration.

User Experience Design

Whenever even a fraction of the system logic was depicted in the form of business analysis outcomes, the User Experience (UX) / User Interface (UI) design activities triggered. That was the ongoing sequence of meetings, preparing designs in InVision software, reviews, collecting feedback, and evaluating UI/UX experience with the product team. When you design an SaMD, you have to consider the end user’s demographic groups defined in PLC Intended Purpose document. As a result, the UI/UX Designer prepared detailed designs of user interface for each of the three platforms: iOS, Android, and a web portal. To create an easy-to-use product experience, the designs had to simultaneously follow  material design principles, corporate identity guidelines, as well as the system logic.Software Developers would also come back with comments of feasibility or technical complexity of the designed UI/UX. Consequently the designer responded to feedback from the implementation phase as well.

SaMD Implementation

The implementation started for the three SaMD products concurrently: iOS, Android, and cloud backend. SDLC Developers were engaged not only in the implementation and integration activities, but also in detailed design, and specification of external interfaces. While implementing, they would come back with feedback as well as questions on specifications or interface designs. If needed, Technology Stacks were extended with new technologies. The code was integrated on various levels, starting with the Continuous Integration (CI) tool, through the execution of unit tests, interface tests, and also final system tests executed by SDLC Quality Assurance Engineers. SDLC Quality Assurance Engineer independently verified any JIRA ticket, resolved by SDLC Developers, to check if the implementation met the specification together with project acceptance criteria.

Verification

Finally, the verification and validation activities. Pro4People defined the approach to verification during the SDLC phase in the Test Strategy document. It outlined a detailed approach to verification and validation activities. It also introduced Acceptance Criteria on each work output on both Maturity/Agile levels. Then, it defined a division of testing effort into  test levels. As a result, the team knew what test levels should be executed on releasing e.g., an Android SaMD product or a cloud backend product.

Test levels did not make much difference when all the products were going live for the first time. At the time all the test levels are executed. They became crucial however to limit the test effort when e.g. only a hotfix of already released Android CE marked application was released. In the SDLC phase, during Scrum Sprints, each resolved JIRA task was independently checked by a Quality Assurance Engineer against the Acceptance Criteria (aka. Definition of Done). This part of testing was called Progressive Tests. At the same time, we gradually extended each test level listed in the Test Strategy, to include more and more test cases (aka. test scenarios) in a TestRail tool. In effect, we had a formalized and ready to use scope of acceptance tests, prior to any version or hotfix release milestones or just after each sprint release.

 

Internet of Medical Things Architecture
Internet of Medical Things

Version Released and Verification 

Finally, the moment to release the three iOS Product, Android Product, Cloud Product arrived. The Project Manager confirmed in JIRA that all D&D activities were completed. Subsequently SDLC Release Packages were built on qualified DEV-BUILD environments. Test Plan documents were prepared for each SaMD product. After that, test levels were executed to prove that each product met quality and also functional requirements. Each of the three products was tested independently, as well as in integration with each other. During these test runs, the SDLC team finalized all the Design and Development documentation. It was subsequently exported  from ins2outs into PDF format – using ins2outs group export functionality.

When the verification was finished, the final Tests Execution Summary Reports were generated. Then products were accepted for release and reports signed electronically on ins2outs, and also exported. Finally, all the D&D deliverables were embedded in a specific version release package, protected from alteration, and subsequently transferred to the Product Life Cycle team level. From that moment on, this version specific release package was a baseline for any future installation, audit, as well as service provision activities.

Summary

Pro4People developed the three medical device products: iOS Product, Android Product, and Cloud Product. Correspondingly a Korean vendor developed brand-new Stimulation Device. To put the products on the market subsequently, Client first coordinated key suppliers’ audits by a notified body and products CE marking audits. In addition to its ISO13485 certificate, Pro4People was audited by an MDR compliant notified body as a key supplier. We also passed the audit with flying colors.

Pro4People formed the Service Provision team to install, validate, and keep the product on PROD-PRODUCTION environments operational. We also provided  Level Two technical support taking responsibility for Service Provision with respect to AWS infrastructure technical maintenance.

All the Client’s products were successfully launched on the British as well as Australian markets. On the SDLC level, a software maintenance phase started on future product versions intended for other EU and US markets.

From the business perspective, our Client took a great step towards executing its digital strategy. In effect the transition from unconnected physical device, to a connected health service became a reality. The data coming from the first production users presented new profiles of end users vs. the predicted ones. It exposed different stimulation device usage patterns than expected. As a result our Client was able to perform in-depth data analysis activities on their medical devices usage patterns.

Lessons Learned

Lessons Learned

We would like to share with you the most important lessons learned from this project from Pro4People’s perspective.

  1. Working jointly on a Program Level. This is one of the most important lessons learned. When you are developing a brand-new medical service, engaging various teams: product, software development, hardware development, solution provisioning – you should define a structure where these interdisciplinary stakeholders and teams can work together. Assign a strong program manager from the Client’s organization who will lead all teams to a common business goal.
  2. Plan from the 10-years+ product perspective. If you start a digital strategy journey, you commit to providing a SaMD service to your clients. It is an ongoing effort, not one-time endeavor. While your hardware projects might still be time-limited, your services must be continuously kept operational, your mobile software maintained, and service data used to support your client. Thus, when thinking about SaMD services, take the 10-years+ perspective, and not just quarterly development cycles.
  3. Mutual trust and focus on resolving issues. When building an Internet if Medical Things (IoMT) in Healthcare solution, there will always be some issues. Build a multifunctional team, empower it with trust, set regular communication channels, and direct them to resolving the issues as they appear. None of the teams can succeed alone, they all must cross the finishing line together. A strong leader on a program level will be of great help here.
  4. Integration, integration, integration. Nowadays, we can forget about simple IT solutions in the Internet of Medical Things. Obviously, an end user should not even notice such complexity, but the IoMT requires at least three different IT products to work together: physical medical device, mobile, and back-end running in the cloud. Robust integration along the full IT product life cycle and technologies used is a must. With this in mind, think about your system integration from the development, maintenance, production, service provision, as well as platform perspectives.
  5. Automate verification and validation. There is a perception that medical devices have slow development and release cycles. You can forget about this cliché with a properly defined release vs. hotfix strategy and also proper test automation. You should automate your verification and validation as soon as you confirm the business case behind the service from day one – if your budget can allow it :).
  6. Start Service Provision early. If you are a new to the SaMD model, you should start defining and understanding the Service Provision (aka. Service Delivery) functions early. This team would install environments, deploy releases and hotfixes, coordinate validation activities, and finally keep the service operational. If that sounds new to your organization, look for assistance here and start it a few months before the planned Go Live milestone.
  7. Start analyzing your data. A client usually launches an Internet if Medical Things (IoMT) solution first to help their end users/clients/patients. The secondary goal can be to learn more about how users are interacting with medical devices. Thus, as an IoMT service goes live there should be some people within a product team to analyze data coming from the service. By understanding how your customers use your products, the organization can help them to resolve the issues they come across, provide assistance, together with personalized therapy. This data also provides invaluable input to help design future new services.

Let’s talk about your project

Information Note

Pro4People sp. z o.o., based in Wrocław, Poland at Wołowska 18 (postal code 51-116), will be the controller of your entrusted personal data. Your personal data will be processed for the period of 3 years from the moment of the last contact. Your data will be processed under the General Data Protection Regulation (GDPR) and derived Polish national regulations. The base for processing is your consent, thus you can execute all the individual rights derived from GDPR at any moment by contacting us at gdpr@pro4people.com. Pro4People may transfer your personal data only to its Trustworthy Suppliers providing supplementary services to us for the purpose specified in this consent.

Pro4People

If you prefer to reach us directly, you can send us an email or call us:

info@pro4people.com
+48 726 700 113
+48 602 148 253

Our office operates from 8:00 to 17:00 CET.

References

Neil Daly - CEO of Skin Analytics

We selected Pro4People as a strategic development partner based on their deep understanding of delivering Software as a Medical Device (SaMD) products. They’ve been engaged, collaborative and an extremely valuable partner.

Neil Daly
CEO of Skin Analytics
https://skin-analytics.com/

Skin Analytics

Dr David Cox - Chief Digital Officer & Co-founder of Closed Loop Medicine Ltd

The team at Pro4People are great to work with. They are professional, flexible and have a huge amount of experience in developing SaMD, so are able to offer a good balance of direction and pragmatism when it comes to developing software under a QMS, whilst holding your hand through the process if it’s not something you’ve done before.

Dr David Cox
Chief Digital Officer & Co-founder of Closed Loop Medicine Ltd
https://www.closedloopmedicine.com/

Closed Loop Medicine Ltd

Tash Thirkell, Operations Manager at ARC Microtech

Pro4People independently reviewed, tested and validated our Medical Device Software to IEC 62304. Working to a very tight deadline, Pro4People’s experience was invaluable and their diligent and supportive team a pleasure to work with.

Tash Thirkell
Operations Manager at ARC Microtech
arcmicrotech.com

ARC Microtech

Related Articles

Medical Device Description

iOS Product, Android Product: Provide optional control of the Stimulation Device utilizing a secure Bluetooth interface, Guide the user in the best way to use the device, Provide a clear and unambiguous user interface for control of the Stimulation Device.

Cloud Product: Securely provide historical usage data to allow feedback to the customer. Provide suggested therapies based on the user’s key symptom and its impact on their lives and help get the best from their Stimulation Devices.

Medical Device Classification

Software as a Medical Device, Internet of Medical Things, Medical IoT, eConnected Health Solution, Adherence Monitoring, Therapy management

Target Markets

UK, Australia, EU, USA, Other

Medical Device Type

Software as a Medical Device, Internet of Medical Things, Medical IoT, eConnected Health Solution, Adherence Monitoring, Therapy management

Medical device users

Lay users using the device in both home and health care institution environments

Relevant diseases

Peripheral arterial disease, chronic venous insufficiency, diabetes, osteoarthritis

Project Duration

~12 months to Minimum Viable Product version of three products

Team Size

Design and Development: ~7 Full Time Employee