Eric D. Schabell: Edge medical diagnosis - Common architectural elements

Monday, November 22, 2021

Edge medical diagnosis - Common architectural elements

Part 2 - Common architectural elements

In our previous article from this series we introduced a use case around edge medical diagnosis 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.

The only thing left to cover was the order in which you'll be led through the details.

This article starts the real journey at the very top, with a generic architecture from which we'll discuss the common architectural elements one by one.

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.

From specific to generic

Before diving into the common elements, it might be nice to understand that this is not a catch all for every possible solution. It's a collection of identified elements that we've uncovered in multiple customer implementations. These elements presented here are then the generic common architectural elements that we've identified and collected into the generic architecture.

It's our intent to provide an architecture for guidance and not deep technical details. You're smart enough to figure out wiring integration points in your own architectures. You're capable of slotting in the technologies and components you've committed to in the past where applicable. It's our job here to describe the architectural generic components and outline a few specific cases with visual diagrams so that you're able to make the right decisions from the start of your own projects.

Another challenge has been how to visually represent the architecture. There are many ways to represent each element, but we've chosen some icons, text and colours that we hope are going to make it all easy to absorb.

Now let's take a quick tour of the generic architecture and outline the common elements uncovered in our research.

Diagnostic facility - Edge services

Starting on the left side of the diagram, which is by no means a geographical necessity, there are two elements that represent external systems that are integrated with the core elements of this architecture.

The first are edge devices, covering basically everything that is used in the field from clinical personnel, patients, to partnering vendors. These can be anything from sensor devices to mobile units such as phones or tablets, but certainly not limited to just these. It's a grouping to identify functionality on the edge of this use case.

The second is called x-ray diagnostic server, a slightly specific element containing all of the remote devices, such as an x-ray machine, capturing diagnostic information such as patient images.

Diagnostic facility - Container platform

These elements in the common architecture are found on location at the diagnostic facilities and can be deployed on a container platform to indicate the cloud-ready nature of this architecture.

The image upload application, is used to take the edge captured images and push them back to the medical center for analysis using complexer solutions than are deployed on site. These can also then be used to improve the various artificial intelligence and machine learning models applied to the detection application. They also provide historical data sets of actual images, that after being anonymised, can further many of the research projects such organisations pursue.

Pneumonia detection application is used in the diagnostic facility on site to analyse the images of patients and provide a diagnosis using models provided from the centralised medical facility. This type of application is being updated often as more images are used to train models and expand the machine learning capabilities for a diagnostic facility.

An image registry provides the images needed to deploy the various applications and is updated by pushing new images from the remote medical facility as updates become available.

A separate anonymise data application is tasked with ensuring any patient information and imagery is scrubbed before transporting to the main medical facility where it's made available for further research test sets, model training sets, and other activities.

The notification application is purely a communication vehicle for necessary information between clinical personnel, patients, and other parties as deemed necessary in the diagnostics process.

Without a doubt, one of the most important aspects to any solution of this nature is the integration of information, storage, and applications which we find here in the distributed streaming services. These services ensure near real-time streaming of data, images, and communications across the diagnostic facility, with the edge devices, all manner of user interactions, and with the centralised medical facility.

Finally, the object storage element is of course used to ensure persistence of all manner of objects, such as patient data, images, diagnosis results, and much more.

Medical datacenter - Container platform

Back in the centralised medical organisation we find the teams that maintain and deliver on the applications, models, dashboards, and the rest of this medical diagnosis solutions.

This collection of elements contains all the base tooling that makes data, models, machine learning, and artificial intelligence applicable for maintaining and improving the medical diagnosis on the edge.

Starting with the top right element in this image, the machine learning element is where models are created, tested on data sets, and tagged for use in the various applications being provided to the edge users.

A dashboard application signifies the ability to monitor the processing of image diagnostics, images, data, and how the entire organisation from edge to backend is performing over time. This can be used to tweak the deployment and usage of the medical diagnostic applications as needed.

The image registry here is used to collect the newly updated and developed application images for eventual sharing out to the image registries located at the supported diagnostic facilities discussed above.

As always, the object storage element is of course used to ensure persistence of all manner of objects, such as patient data, images, diagnosis results, and much more.

The image upload application is used to take the edge-captured images pushed from the diagnostic center for analysis. These are also used to improve the various artificial intelligence and machine learning models applied to the detection application. They also provide historical data sets of actual images, that after being anonymised, can further many of the research projects such organisations pursue.

There is a manual classification application that helps the clinical personnel with medical diagnosis where full automation was unable to bring a case to conclusion.

Finally, we find a machine learning CI/CD element that is used in the development cycle for testing and building images for deployment of applications and other tooling to the image registry.