Making borderless remote healthcare a reality with 5G

For the past three years Ericsson worked with many Service Providers to achieve the on how to build a global network for healthcare: Orange, NTT, Vodafone, Verizon, Deutsche Telekom, TIM, Telus, Telenet, Chunghwa Telecom, British Telecom, Du, Hong Kong Telecom, Sparkle, a number of partner vendors Amartus, Infosys, EXFO, IOTA, BearingPoint//Beyond and doctors and Universities, Università degli studi di Milano, Université de Paris Ilumens Medical department and Meiji University in Tokyo, collaborated to design and confirm the requirements from a business and technical point of view.

The result is a future looking environment that allow the healthcare professionals to access and interact with each other on a global scale potentially allowing the fastest possible reaction and sharing of medical services when they are needed the most. The names of the Catalysts are reflecting this futuristic view: 2018 was “Blade Runner”, 2019 was “Skynet” and 2020 was “Ghost in the shell”. Thegroups working with these Catalyst projects analyzed different aspects of the global network to provide a high-level blueprint, based in industry standards such as and initiatives such as Telemanagement Forum Frameworx, Open Digital Architecture (ODA) and OpenAPI, ONAP, GSMA NEST, MEF LSO and TOSCA service modelling. 

The analysis went through various stages. The more we analyzed the need, the more we understood that the technical aspect is just a part of the whole picture.

First: we don’t know when and where a pandemic is going to explode or when or where an outbreak is going to happen. That means the Service providers, the hospitals and the universities need to be ready before the event happens. Therefore, this means that in order to handle the emergency, the daily business model must be sustainable (and profitable!) so that all the elements are in place in advance.

Second: doctors and medical universities do not know or even care about telecom capabilities. They know medical services and they talk medical language. Therefore, any platform that is used by them, no matter how complex it is, it should provide them an interface that adhere to the language they know and desire to talk.

Third: governments strictly regulate healthcare services. These regulations usually go through governmental bids that might take years to finalize. One more reason to get ready in advance to help the healthcare through global emergencies.

Fourth: the true advancement we can bring is related to the actual medical capabilities. Currently there is no possibility to access medical knowledge from a different country as quickly as it’s desirable. A doctor with the right capabilities might be available in a different country, and he potentially could perform a remote surgery or teach students, but the communication layer is not available for him to do it. So today he would have to be contacted and travel to the destination where he’s needed, and that can easily take days when possible at all. With our approach and 5G network slicing we could reduce this connection to a matter of minutes, using today available technology.

Fifth: the network slices and resources required for these high performing intercarrier services are expensive. They cannot be pre-allocated waiting for somebody to use them, but they should ideally be used only when needed by a customer. This led to the target of having network slices instantiated on demand and dedicated to a customer.

These reflections drove us to design an architecture interconnecting hospitals and universities worldwide using the Service Operators networks advanced capabilities.

Talking with the end users, working and developing the medical applications, we realized they currently rely on best effort performances from networks. 

Their general approach is: if my network is too slow (due to latency) I need more bandwidth!

While it’s obvious to professionals that bandwidth and latency are related but disconnected metrics it’s clear why they’re doing it. The devices are connected to a local Wi-Fi network, and the perception is that the capacity of it is not enough, hence the reaction to increase the bandwidth. That brings us to two main issues:

• Medical devices should be connected directly to the 5G network to perform properly;
• Hospitals and Universities need to be informed of the capabilities of 5G and Network Slicing so that they can better direct their investments. If they need lower latency for some applications (e.g. remote surgery) they should ask and contract for lower latency!

The other aspect that was crucial for our catalyst was related to the actual interconnection of the end points.

While in the best case the two endpoints, hospitals or universities, might be managed by the same Service Provider, in the worst case scenario they might be in two different continents and managed by Service Providers that do not belong to the same group. We focused on this scenario, briefly depicted below, so that we could achieve clarity on the need.

On the left we see the requesting party, where the actual patient is. It might have a dedicated healthcare application running on a local client, let’s say in Paris, France.

The application server, being it a real application or a doctor providing a service, in our example is in Milan, Italy

The local hospital will have a contract with a local Service Provider (that in our case was represented by Orange). Orange will maintain therefore all the contract SLAs related to the delivery of the complete service.

Orange will have two subcontractors for this specific service:

• A transit provider
• A Last Mile service provider

The transit provider (In our case Sparkle) will provide the connectivity between the two countries, connecting Italy to France.

The last mile Service Provider has the capability to instantiate the connection with the endpoint in Milan where the application server or the doctor is. It is important to clarify that the universities and the hospitals have coverage negotiated with Service Provided in advance, so the requesting party (Orange) can’t choose which Last Mile operator to use, but has to align to the one that has the contract to cover the endpoint.

In the next entry of this blog I will provide more details on how we designed and managed the interconnection of this parties.

Learn more about network slicing and how it can support different businesseses