How to develop AI for Health Software? – SDLC Approach

by Tomasz Puk, Dariusz Nabiałczyk | Nov 09, 2018 |

In this article we would like to share with you our experience in developing Artificial Intelligence components from a software engineering perspective. For this reason, we will have a look at different phases of developing AI for health software. By health software one should understand software incorporated into medical devices (for details please refer to IEC 62304).

Should you wish to talk to us about supporting you in such a project, please check out one of the below links.

Disclaimer
We intentionally decided to skip value proposition considerations concerning your AI but surely that is the most important step to start any new project development.

Documenting Software Requirements to AI

And here comes the biggest difference between AI and traditional algorithmic programming…

On the one hand, in software development traditionally you documented your data input algorithm that would transform the input into expected results. An algorithm fed with specific input would always lead to a precise result with 100% certainty.

On the other hand, when developing AI you provide data and expected results. The outcome of software development is a neural network and its configuration models. Such a couple with a specific probability shall turn input data into expected results. That is the classical heuristic approach; providing a specific data input will result in specific data output, but within limitations of probability e.g. 80% or 90%.

From the above two approaches we can derive a different strategy to documenting intended use and software requirements. You should consider the specifics of an AI software component and firstly reflect on its intended use. Using an AI component for “advisory”, “data processing” services presents no difficulties. Additionally, you can address the “result probability challenge” with having the outcomes checked by humans or controlled by deterministic software component.

Whatever solution you design the software requirements should reflect this intended use. Never assume 100% accuracy of the results when specifying your software requirement. Instead, define the anticipated accuracy of your health software AI in terms of probability. Please note that humans quite seldom make diagnosis with 100% probability either so the regulator should not have any issues with that.

Some other software requirements worth adding at this moment are, for example: protecting your neural network models with cryptographic controls, identification of your AI version used for data processing, always sending the results together with the AI version from the AI software unit, monitoring, proper initialization of AI etc.

Select Proper Technology Stack for AI

The first thing to do is to correctly select the best Technology Stack for developing and hosting your AI software unit.

Development Language – you should decide what language for developing AI’s network topology will be used. For example, on the one hand, if you decide to select one of scripting languages your development may be faster but protecting your AI configuration and models within a production environment will be trickier. On the other hand, having the final AI network and configuration working on a component compiled to a binary executable will make your solution firstly much safer and secondly more efficient as well.

Training Environment – this is the second decision to consider. Where are you going to train your neural networks? You have a wide range of options here starting from cloud provided GPU units e.g. Amazon EC2 Elastic GPU to dedicated hardware for that purpose e.g. Razer CORE v2. In Pro4People, we usually use our own hardware graphical cards for neural network design, training and optimizing. As a result, we can bring the initial software development costs down. Additionally, we can achieve higher security in the software development phase by limiting that to our inside office perimeter.

Already within that phase you should have brought all the cryptographic controls into the game to protect your AI models. Additionally, you can think about patenting your proprietary network configurations / models.

Production Environment – finally, you have to decide on what infrastructure your AI will be operating. We usually see here that the AI is deployed to cloud infrastructure like Amazon EC2 Elastic GPUs since it offers your solution horizontal scalability options. As such services usually come at a quite hefty price, the proper architecture (pay-as-you-go approach) will help you to keep costs at bay.

AI Design Training and Optimizing

The most important part of AI software development is designing, training, and optimizing. Within that phase you will have to select or design a neural network which is the most suitable for the problem you are going to tackle.

Network Topology – What kind of network will work the best for the problem you want to tackle to offer new value proposition? Will you go for any of the well-known classes like e.g. Convolutional Neural Networks (CNN), Recurrent Neural Networks (RNN) or Long Short-term Memory Networks (LSTM)? Does your problem require developing more sophisticated topologies (e.g. ZF Net, VGG, or ResNet), or even your own proprietary neural network topology? If you have no idea how to start that, do not worry -check this out: https://pro4people.com/ai-powered-solutions/

Data Curation – This is even more important as your network configuration. The goal of this step is to prepare data that will be used to train your neural network. You should have both the input data and the expected results prepared. The more reliable your data set is, the higher the chances of training and optimizing the AI model that will fit your needs. Please, protect your data as well. Having your data set and the expected outcomes a competitor can come up with their own AI configuration. You will also need that data later for Verification and Validation of your medical device. It will be also used in clinical trials.

Training / Optimizing – At this stage you have your chosen network topology and data ready for training. Now it is time to train your network, optimize it, and keep repeating this process over and over again until you fall within the probability expectations specified in your software requirements. It takes time, computing power and knowledge 😉 to train your network, polishing learning data, modifying neural network topology, and re-evaluating learning processes. In order to cut costs in this phase we usually do the training on physical HW in our company or in a cloud, including powerful machines supported by GPUs. Please remember that not all topologies have a support in GPU optimization and it also gives you an opportunity to optimize computation beyond the utilized AI framework.

Integration – The integration is a very important stage of your development. You have to integrate your AI software unit with the rest of the system architecture. The interfaces should be precisely specified, as quite likely your AI will be released quite often. Thanks to carefully specified interfaces your AI can be both forward and backward compatible from a product life cycle perspective. Equally important are the questions of scalability. Operating a EC2 Elastic GPU comes with a hefty price tag. If you design and integrate your solution with horizontal scaling, you can save costs and take advantage of a pay-as-you-go approach.

Software Unit Identification

Well, we all know the identification focus when developing software for medical devices, don’t we? 😊 AI does not differ here at all. Consider closing the AI component as a separate Software Unit in your system architecture. This way you can benefit from its quite likely more frequent releases of new, better trained neural network in the future. Such a component should always identify its version and the models applied. It should be enough to identify the configuration used in making decision / processing health data in your system. Please, remember to store this version together with the processing result so you will always be able to say which version of your health software turned data into information / result.

Verification & Validation (V&V)

When considering AI software unit verification and validation approach it does not differ from testing any other software unit. The typical configuration of test cases could be:

  1. AI software Unit Test Level
  2. Integration Test level
  3. User Acceptance Tests – in the scope specific to software requirements specific to AI

The verification part of testing shall be covered within your R&D environment as a part of Software Development Life Cycle. The validation, as it shall be executed in production environment, usually can be postponed to version deployment and its validation. It is a good practice, to separate AI Software Unit Test Level as a separate automatic testing component. Then, running this test level can be done on any environment even in the continuous manner. Please, note that quite likely your AI may be a subject / part of your clinical studies in case they are required for your medical device software.

Security and IP

When thinking about security of your AI please consider at the very least the following elements:

  1. Is data sent to be treated as personal data? If so it should be encrypted due to a GDPR requirement.
  2. Are your data models encrypted? Even though it is not obligatory you should do it to protect your IP. Use cryptographic controls specified in you Cryptographic Control Policy as required by ISO 27001.
  3. Is your AI software unit operating in a secure environment?
  4. Is your AI software unit being monitored? ISO 27001/GDPR requirement.
  5. Is your AI software unit logging all abnormal behavior? ISO 27001 requirement.

Once you have specified your expectations here it is good practice to turn them into software requirements as well. The last thing you may consider here is patenting your AI topology and models but that is a different subject.

Software Release

Finally, we have come to the moment to release our software system. The AI software unit will be one of its components. We follow “standard” release procedure (ISO 13485 + IEC 62304) and have an AI component and its models uniquely identified. We should run all the tests according to the test plan for this release, but certainly, they will cover the three aforementioned: AI Software Unit Test Level, Integration Test Level, User Acceptance Tests. After meeting all the acceptance criteria specified in the Test Plan we should be ready to upload the release package to Definitive Media Library from where it can be taken over by a Product Team.

Post Market Surveillance

OK… so your product is about to Go Live! Firstly, you should be aware that your AI is going to be exposed to a large amount of data. Once released, the AI software unit cannot be altered without another release but you can still use this data for training and optimizing the next version of your AI component. Basically, you need to run two data streams in parallel: one for already approved and validated medical device software and the other for the new version of the AI unit, if required. As a result, your AI unit should improve with each new release.

Should you wish to learn more, or talk to us about supporting you in such a project,
please feel free to contact us:

Contact us

Above we have discussed the major phases of the AI software unit component along with both Product Life Cycle and Software Development Life Cycle. Should you wish to talk to us about supporting you in such a project, please check out one of the below links.