Eric D. Schabell: Edge medical diagnosis - Example predictive analysis

Thursday, November 25, 2021

Edge medical diagnosis - Example predictive analysis

Part 3 - Example predictive analysis

In our previous article from this series we talked about the logical common architectural elements found in an edge medical diagnosis solution for the healthcare industry.

The process was laid out how we approached the use case and how portfolio solutions are the base for researching a generic architecture. It continued by laying out the process of how we approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.

Having completed our discussions on the logical view of the architecture, it's now time to look at a specific example.

This article walks you through an example predictive analysis scenario showing how expanding the previously discussed elements provides an example for edge medical diagnosis scenarios.

Architecture review

As mentioned before, the architectural details covered here are based on real solutions using open source technologies. The example scenario presented here is a generic common architecture that was uncovered while researching those solutions. It's our intent to provide guidance and not deep technical details.

This section covers the visual representations as presented, but it's expected that they'll be evolving based on future research. There are many ways to represent each element in this architecture, but we've chosen a format that we hope makes it easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.

Now let's take a look at the details in this architecture and outline the solution for two views of the edge medical diagnosis architecture solution.

Edge medical diagnosis (network)

The first look is of the overall architecture for edge medical diagnosis with the details filled in that were discussed as logical elements previously. Starting on the left side of the diagram, there are two entry points for the actors you can expect for this use case. One is representing the edge devices, in this case an x-ray machine behind the x-ray diagnostic server, which is collecting the initial images. The other is the medical staff in the clinical environment receiving notifications for results from the automated image analysis and diagnosis process. On the right side of the diagram you find the development user, a data scientist.

First we will explore the edge devices, from the x-ray diagnostic server, as images make their way through the architecture. After that, we'll examine the medical staff as a user and the interactions they have with the architectural solution. Finally, we'll swing to the other side and dive into the process flow of a data scientist as they develop their solutions for this architecture.

The images enter the container platform as they are collected by the image receiver which is a Python application in this architecture. The images are then persisted, passed to the pipeline dashboard to provide an overview of a diagnosis process in progress, and given to the pneumonia diagnosis application for analysis. Here the application is using the provided data and models provided together with artificial intelligence to assess images for pneumonia. At the same time, these images and the data associated with them are being cleaned up by the data anonymisation application before they are transferred back through the streaming integration services to the central medical data center into the x-ray storage element.

The medical staff is waiting on their systems for the notification service to alert them when a diagnosis is ready for them to examine. Some images might lead to the medical staff having to make the diagnosis themselves, but more often they are notified that the specific patient images have been detected (or not) as containing traces of pneumonia.

Back at the medical data center, the data scientist is tasked with defining, modifying, and continually working with the stream of new images and data that the diagnostic facilities are generating. She uses all of that data along with the data science tooling to continually improve the manual classification application. The source code management system (SCM) together with the machine learning CI/CD tools generates new application images for the image registry. These application images are shared back out to the diagnostic facilities' image registries for deployment to update the existing applications in their process.

Finally there is a facility statistical dashboard used to provide an overview of the entire medial diagnosis architecture's performance.

While this view is of the network connections, it's not a hard binding for your own architecture. Think of this as the rough outline of what a successful architecture looks like and mapping that to your very own situation is a matter of applying your domain knowledge together with this guide.

Next up, a look at the architectural solution with a focus on the data view.

Edge medical diagnosis (data)

Data connectivity through the edge medical diagnosis architecture provides a different look at the architecture and gives us insights into how one of the most valuable assets of a healthcare organisation is being processed.

It should be seen as the architecture is intended, as a guide and not a definitive must-do-it-this-way statement on how the data is being routed through as actors are engaging with the systems, applications, and services in this architecture.

Note that many of the data flows only one direction while it's fairly obvious it's going to flow both ways. We've chosen to note that in the flows that do not disrupt the clarity of the architecture diagram, and chose not to indicate where the intent is to show processing and flows for clarity from actors to systems on the backend.

It's left to the reader to explore these data diagrams and feel free to send comments our way.