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)
In a medical device class project to be described, our client was a UK-based consumer health technology company offering drug-free and clinically-proven health solutions. The company was established in 2003 and ever since has been developing medical device class products intended to be used by lay users both in home and health care institutions environments. The company’s main product is a Stimulation Device launched in the UK in 2005 and sold in more than two million devices in 13 countries worldwide, including the EU, the USA and Australia.
The company has additionally been offering a portfolio of other Medical Device class products/solutions for patients suffering from such diseases as: peripheral arterial disease, chronic venous insufficiency, diabetes, osteoarthritis and chronic obstructive pulmonary disease (COPD).
Business Goals – IoMT in Helthcare
The Client, as a part of its long term Digital Strategy implementation, decided that the next generation of its flagship product, the Stimulation Device, would be a connected medical device. The new version of Stimulation Device offers significant functional and therapeutic improvements compared with its previous design.
In addition, thanks to the connectivity paradigm, it offers the following advantages over its unconnected variants:
- connects the Stimulation Device, an edge medical device, to a medical device class mobile application on both Android and iOS platforms;
- controls the edge device with a mobile app, allowing further improvement of the patient’s User Experience (UX);
- enables end users to receive contextual materials, personalized assistance, and direct support, resulting in more effective usage of edge medical devices;
- sends usage data to the medical device class backend system, enabling Client to take actions on the end user device user patterns;
- offers personalized therapy to end users based on their individual targets and up-to-now therapy outcomes;
- increases end users’ adherence to the assigned therapies resulting in improved health and wellbeing;
- starts offering supplementary health services directly at home and health institutions’ environments.
On the Digital Strategy level, the Client planned to:
- make a transition from manufacturing physical devices to a supplying connected, clinically-proven health solutions and services;
- extend digital competencies in the organization;
- start collecting data about how end users interact with medical devices;
- stay closer to its users, shorten communication channels, provide instant feedback and support;
- start offering personalized services for end users;
- validate its digital strategy with taking its first step towards its implementation.
Selecting a Design and Development Supplier
The Client was looking for a company that would fully take the responsibility for leading, developing, and finally supporting CE marking of the Software as a Medical Device (SaMD) product(s). The supplier was supposed to lead the activities in respect of Software Development Life Cycle (SDLC) , triggering, if needed, Product Life Cycle (PLC) activities, and finally closely collaborating on integration with a South Korean hardware vendor that develops the edge medical device.
As far as regulatory/technical perspective was concerned, the Client was looking for a supplier that would have practical experience in developing Internet of Medical Things (IoMT) solutions on the service design, engineering, and regulatory levels. The supplier was expected to operate under the 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. Another competency expectation involved defining and implementing functional requirements derived from global security/privacy regulations and standards (such as HIPAA, GDPR, CCPA, or ISO27001:2019) in the SaMD device.
As the Client planned to launch the service on a global market from a day one, the supplier was supposed to be expert in Amazon Web Services (AWS) Cloud or any other cloud provider; responsible for developing cloud backend, 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, and still provide flexibility and maintainability over 10 years+ predicted SaMD product life span. The solution architecture needed to be applicable globally, with practically unlimited growth capabilities.
Pro4People was selected as a design and development partner after several presentations (including two UI/UX presentations for mobile applications) and direct meetings, revealing its Quality Management System, medical device projects track record and experience, and several revisions of the approach to the project’s management and schedule.
Product and Project Teams Collaboration
As one of the first steps, Pro4People suggested establishing a program management structure. In order to deliver a system consisting of an edge medical device, mobile applications, a cloud backend, with a support team helping clients in any problematic situations, a program management team was established. Subsequently, a Product Manager was appointed. The goal of the program management was to coordinate activities on the following levels:
- Product Life Cycle (PLC) – managing product value proposition, defining functionalities, product requirements and alignment with the client’s business and digital strategies;
- Software Development Life Cycle (SDLC) – managing development of cloud backend, and mobile applications Software-as-a-Medical-Device (SaMD) projects (Pro4People);
- Design and Development Edge Device – managing a new, connected version of Stimulation Device (the Korean vendor);
- Service Provision Team – building a brand new team that would be responsible for provisioning and keeping the final system (consisting of all developed medical devices) operational, once it has been placed in the market.
On the PLC level, the Client appointed the following stakeholders to manage the program:
- Program Manager – responsible for coordinating all the projects that finally comprise a complete system. One of the most important roles pertaining to integration, resolving issues, challenging the status quo, and simply “making things happen” in all parallel projects.
- Product Manager (aka Product Owner) – having a product vision, defining value proposition, working on a business model. That person was also responsible for defining product and software requirements, risk analysis activities, approving or rejecting use case or system functionalities.
- Quality Manager – responsible for defining regulatory requirements, the alignment of both the Client’s and Pro4People’s QMSes, and leading the certification audits of suppliers and final CE marking of all the products.
- Head of Industrial Design – responsible for defining, supervising and leading the industrial design decisions in all concurrent projects. As a result, the unified User Experience and User Interface aligned with corporate identity was delivered to end users.
From the SDLC level, Pro4People appointed the following persons engaged in the communication on the program level:
- 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 the past relative medical projects, e.g. a list of MDR, HIPAA, or security-by-design requirements. The Project Manager coordinated the SDLC team effort estimations. They were then used to inform the product team about what could be implemented, about how much effort was needed, and were essential in the continuous discussions on the roadmap planning against set business milestones. On the Agile level, the team followed Scrum methodology, working with two-week sprints, embracing change, deploying fortnightly versions to demo environments for the product team to verify and come back with the feedback.
- Business Analyst – responsible for communication with a Product Manager (aka Product Owner) and 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. As a result, the Business Analyst worked as the primary owner of the product vision in the software development team, explaining to the engineers what the product team wanted to achieve, and to the product team – the implementation itself, its limitations, and delivered functionalities.
- UI/UX Designer. That role was 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. As the outcome, 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, e.g . InVision, were used for that purpose, lowering the cost of experimentation, reiteration and significantly reducing any rework when a finally agreed UI/UX design was implemented. The UI/UX Designer had to use their vast experience, work closely with the Business Analyst, in order to design a UI/UX which significantly simplified medical device usage and offered additional therapeutic outcomes for end users.
- Quality Manager. Pro4People’s Quality Manager worked closely with the Client’s Quality Manager to decide which process defined in both organizations’ QMSes should be used where. That resulted in a clear definition of working standards to be followed, and finally, in no issues during both Supplier Audit and CE marking audit from a renowned notified body. Secondly, our Regulatory Expert, helped to define an SaMD product regulatory strategy suggesting how a system shall be divided, developed, and documented so as to make it less prone to regulatory risk derived from changes in SaMD software when a product is put on the market.
Software-hardware integration was another very important collaboration level. It required excellent communication between the Pro4People mobile Apps team and the Korean team developing the edge medical device. The goal was to agree upon the communication technology, API specification, translation of application use cases into API calls, implementation, integration, as well as automated and manual testing. It would not have been possible, without a strong support from the Program Manager, directing all the development projects towards a common business goal and release. The software-hardware integration was done daily, all the problems were documented in JIRA and then attributed either to mobile applications or edge device developing teams for further investigation.
Setting up a Service Provision Team gained importance as the project was approaching the GoLive milestone. A need for new functions with the program management structure appeared: Level Two, and Level Three support. On the other hand, the Client used the already existing Service Desk for Level One support function. In order to facilitate the system roll-out, Pro4People offered a Level Two technical support, in addition to design and development activities. It covered executing such technical service operations activities as: installation, deployment, validation, monitoring, maintenance, and finally operations management process compliant with both ISO13485 and ISO27001 standards.
Start your Medical Device Project
Design and Development of IoMT 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. Thus, the communication in D&D was centered on a business level and 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 its software development planning. In order to meet requirements of the Maturity software engineering approach, but also standards such as ISO13485, ISO14971, IEC62304, the Project Manager prepared planning documents using Pro4People templates. The plans covered the following elements of the Software Development Life Cycle:
- SDLC Software Development Plan – describing an approach to software development and maintenance.
- SDLC Test Strategy – outlining verification activities, test levels, acceptance criteria and a link to the product PLC Verification and Validation Strategy.
- SDLC Configuration Management Plan – presenting an approach to managing configuration, infrastructure, baselines, environments, identification etc.
- SDLC Risk Management Plan – helping to document how ISO14971-defined risk management activities are executed on the SDLC level.
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, and presenting and 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. Thus, the SDLC team had to plan for documentation management. The scope of the documentation proposed by Pro4People derived 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 were derived from the already existing Pro4People document templates and used within ins2outs documentation management system.
To develop an SaMD solution a proper Architecture and Technology Stack should be designed. If the system must meet regulatory requirements, be ready for multi-site deployments across the globe, and at the same time meet the regulatory requirements, you have to rely on a partner with robust experience in that domain. Pro4People designed an Amazon Web Services (AWS) architecture following a loosely coupled architectural pattern, which, in that case, seemed to be better suited for a medical device domain thane.g. a microservices one. It assured both horizontal and vertical scaling, made the service unlimited from the infrastructure perspective, while 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. Interested to learn more? We recommend reading about Inverse Conway Maneuver and considering what challenges that would create for a company executing first steps in its Digital Strategy.
A technology stack for each SaMD product was built on robust and trustworthy technologies which met the requirements derived from supplier risk assessment. When planning an SaMD, you must consider 10-years+ perspective of the product’s presence in the market. Thus, selecting a proper technology stack is a key decision that most business stakeholders may not even be aware of. This decision will 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 the future. It was additionally driven by the needs to fine-tune the applications to such platform-specific functions as Bluetooth communications.
Configuration and infrastructure management with respect to both the development and production environments constitutes a very important part of the software development, especially for cloud deployed systems . Within Pro4People, it was the role of a SDLC DevOps Engineer who was in charge of these activities on the SDLC side . The DevOps 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 and other elements required by standards and regulations . In respect of infrastructure management, Terraform was used to automate the process of installing a new environment first, and then deploying a new product version to the already set-up environment. Finally, an Operations Manual was written, describing how a production system shall be monitored, backed up, restored, deployed, and kept operational.
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. It required continuous communication with the Product Manager and the Head of Industrial Design functions. The human-computer interaction spread from the edge device, through the Bluetooth connectivity, then via a mobile application, to finally communicate with a cloud backend. In addition to that, the Business Analysts were in charge of documenting software requirements, including 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. Taking into account the fact that the system life-span had been planned for 10-years+, 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. It allowed not only to meet the IEC62304 requirements, but above all, to be able to grasp and manage a system vision over its predicted life span despite any changes in the team configuration.
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 do it considering the end users demographic groups defined in PLC Intended Purpose document. 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 follow material design principles, corporate identity guidelines, as well as the system logic simultaneously. The designer was also expected to respond to the feedback from the implementation phase when Software Developers would come back with comments of feasibility or technical complexity of the designed UI/UX.
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, to a certain extent, in detailed design preparation. The developers would also specify some of the external interfaces. While implementing, they would come back with feedback and 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 final system tests executed by SDLC Quality Assurance Engineers. Any JIRA ticket, resolved by SDLC Developers, would be independently verified by a SDLC Quality Assurance Engineer to check if the implementation met the specification and project acceptance criteria.
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, introduced Acceptance Criteria on each work output on both Maturity/Agile levels. Then, it defined a division of testing effort into the so-called test levels. Thanks to that, the team knew what test levels should be executed on releasing e.g., an Android SaMD product or a cloud backend product. Things did not make much difference when all the products were going live for the first time and all the test levels were executed. Yet it became crucial to limit the test effort when 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. In parallel to that, each test level listed in the Test Strategy, was gradually extended with more and more test cases (aka. test scenarios) in a TestRail tool. Thanks to such an approach, a formalized scope of acceptance tests was ready to be used prior to version or hotfix release milestones or just after each sprint release.
Version Released and Verification
Finally, the moment to release the three iOS Product, Android Product, Cloud Product arrived. When the Project Manager confirmed in JIRA that all D&D activities were completed, three SDLC Release Packages were built on qualified DEV-BUILD environments. Test Plan documents were prepared for each SaMD product and then a test levels were executed one after another to prove that a product met quality and functional requirements. Each of the three products was tested independently, and then for integration with each other. During these test runs, the SDLC team finalized and exported all the Design and Development documentation from ins2outs into the PDF format – using group export functionality. When the verification was finished, the final Tests Execution Summary Reports were generated, products accepted for release, reports signed electronically on ins2outs, and then exported as well. 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, and service provision activities.
The three medical device products: iOS Product, Android Product, and Cloud Product were developed by Pro4People as a part of this project. In addition, a brand-new Stimulation Device was developed by a Korean vendor. To put the products on the market, Client first coordinated key suppliers’ audits by a notified body and then products CE marking audits. In addition to its ISO13485 certificate, Pro4People was audited by the MDR compliant notified body as a key supplier, and passed the audit with flying colors.
The Service Provision team was formed to install, validate, and keep the product on PROD-PRODUCTION environments operational. Pro4People offered here Level Two technical support taking responsibility for Service Provision with respect to AWS infrastructure technical maintenance.
All the Client’s products were successfully launched both on the British and Australian markets. On the SDLC level, a software maintenance phase started on next product versions. These versions are planned to be put on other EU and US markets.
From the business perspective, Client took a great step towards executing its digital strategy. 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, and exposed different edge device usage patterns than expected. As a result, the Client started in-depth data analysis activities on their medical devices usage patterns.
We would like to share with you the most important, from Pro4People’s perspective, lessons learned from this project.
- 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.
- Plan from the 10-years+ product perspective. If you start a digital strategy journey, you commit to provisioning your 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 quarterly development cycles.
- Mutual trust and focus on resolving issues. When building an 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.
- Integration, integration, integration. Nowadays, we can forget about simple IT solutions in the IoMT. Obviously, an end user should not even notice such complexity, but the IoMT requires at least three different IT products to work together: edge, mobile, back-end. Thus, the robust integration along full IT product life cycle and technologies used is a must. For that purpose, think about your system integration from at least development, maintenance, production, service provision, and platform perspectives.
- Automate verification and validation. There is a perception of medical device being slow in development and release cycles. You can forget about this cliché with a properly defined release vs. hotfix strategy and 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 :).
- 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. That team would be installing environments, deploying releases and hotfixes, coordinating validation activities, and finally keeping 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.
- Start analyzing your data. A client usually launches an 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, personalized therapy or may just start designing and offering new services.
Let’s talk about your project
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 firstname.lastname@example.org. Pro4People may transfer your personal data only to its Trustworthy Suppliers providing supplementary services to us for the purpose specified in this consent.
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.
CEO of 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
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.
Operations Manager at ARC Microtech
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
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
Peripheral arterial disease, chronic venous insufficiency, diabetes, osteoarthritis
~12 months to Minimum Viable Product version of three products
Design and Development: ~7 Full Time Employee