Small development team makes large impact on global medical education

How do you make it all work?

Johan: As a small team, we need to be agile and quick on our feet. Our processes are generally fast. If someone says that something doesn’t work, we need to try a different solution. However, breaking it down a bit more, what we are doing is a form of iterative design. We identify the issues that we have in our system, prioritize them, and then start addressing the most pressing one. But crucially, we don’t do it perfectly. We don’t build the perfect replacement. Instead, we do it well enough so that it is better than before. Then we deploy it so that our users can start using it quickly. While we are building the next solution, we get feedback from our users, take that feedback into account, and as soon as the next solution is done, we reprioritize and repeat. The aim is to avoid making changes to our main system, the Sectra PACS. Instead, we want to build things around it to make it more accessible to our type of user.

What are some of the most important features of the ideal educational tool?

Johan: Firstly, it needs to available everywhere. We want to make sure students can use our solution not only at campus, but also from their personal devices at home or even on the bus. Secondly, deployment needs to be very easy, at the click of a button. Thirdly, our solution is aimed at medical education students. We want to make it as easy as possible for them to use it. And finally, the main point, the impressive content of our solution. We have a library of clinical images that all students can access. It is this library that they will use to improve their learning.

What about the Sectra PACS?

Johan: The Sectra PACS is the basis for Sectra Education Portal. For anyone who doesn’t know exactly what this is, it is a picture archiving and communication system (PACS) that stores medical images—a large and complex Windows application that is installed at the hospital premises. It is aimed at trained medical professionals and allows them to communicate about these images with their peers. They can also interact with the images in various ways so that, in the end, they are able to make a diagnosis.

How did you use the Sectra PACS in your medical education solution?

Johan: We started off by creating a cloud instance of the PACS, allowing our users to launch it through the internet. As soon as they had downloaded the local client, they could start accessing the library of cases. However, a PACS is not ideal for educational use. In fact, there are a few main differences between a clinical use case and an educational use case.

Let’s start by talking about the workflow. For clinical use, the prime subject is always the patient. Crucially, you cannot ever be allowed to mistakenly click a button and end up looking at another patient’s information. For educational use, the opposite is the case. We care about the typicality of the case. To learn about, for example, lung cancer, you want to be able to see one or a couple of different images of a tumor, and you might also want to see a healthy lung as a comparison. Sectra
Education Portal lets you do just that. Most importantly, all images are anonymized.

Now, let’s talk about scale. At a hospital, you generally tend to have a stable number of set users, whereas at a university you have hundreds of new users every year. Also, on premises at a hospital, users upload a lot of images, they communicate about these images and there are many case changes every day. Students, on the other hand, do not produce data—they consume it.

Deployment is also different. The PACS is installed on premises on the hospitals’ Windows machines where we control the whole network and the servers. At universities, deployment must be a lot easier and instant. The solution must also be available on different operating systems.

What about the new generation of Sectra Education Portal?

Johan: The main issue with putting the PACS in the cloud was that teachers found it very difficult to find relevant cases. There is a lot of information with a focus on the patient. For educational purposes, this is not ideal. For a teacher who wants to put together material for their next lesson, this ends up being a challenge, so we needed to help them find the right images. But we did not want to change the PACS database. Instead, we created a separate database with meta data about our cases. We built a visual gallery with snapshots and information about each case, and when our users click on the thumbnail, they launch the actual case in the PACS client. In this way, we can now help teachers find relevant cases for their classes, and students can also find similar cases by themselves.

And the future?

Johan: Launching the PACS client is a bit inconvenient, and our goal is to be able to use the solution on every device. Since the PACS has a web viewer, we are taking this and putting it in the gallery as well. This means that when you click on a thumbnail, you will no longer launch the PACS application. Instead, you will get an iFrame with the web viewer inside it.

It will allow you to interact with the images, scroll through stacks, take measurements, etc. We hope to launch this further improvement quite soon.

Still, we are not quite satisfied yet because we have one more big decision to make. The native client has a nice feature for educational use—3D rendering. This requires a Windows client, and we need to figure out how to solve that. The biggest decision is therefore whether to do it client-side or server-side. If we choose the client-side option, we will need to transfer the data in bulk from the server to our client. The client will need to have a web application that transforms that data into a volumetric texture on the GPU and renders it as a point cloud or voxels. This has the advantage that everything is done on the customer’s device, and there will be no latency depending on where you are. Once you have transferred the data, you are good to go. The bad news is that we do not have a webbased renderer today, and we would also need to handle all the interactivity of the advanced tools of our solution. Not all computers will have a GPU that can render this fast enough, and there will of course also be compatibility issues.

We could opt for the server-based solution. We have a cloud already so we can just use it even more, spin up a bunch of servers and allocate new nodes dynamically. We already have a server-based renderer that we would need to adjust slightly. I think this would be much easier to develop than a whole new renderer, and we wouldn’t have to worry about compatibility issues. There is a disadvantage in terms of latency and costs though.

However, to be able to decide, we will prototype both solutions, deploy them to a group of test systems and see where we end up. As a rule, we don’t want to fix something that isn’t broken until we have something that works better. We are ready to find a better solution than what is currently available, launch it and let our users decide what is wrong with it. Then we can reprioritize and improve it further.