Content for TR 22.826 Word version: 17.1.0
5.4 Moving - Local
5.4.1 Description of Modality
5.4.2 Cardiac telemetry inside hospital/care facility
5.5 Moving - Remote
5.5.1 Description of Modality
5.5.2 Patient monitoring inside ambulances
5.5.3 Cardiac telemetry outside the hospital
5.4 Moving - Local Word‑p. 42
5.4.1 Description of Modality
Hospitals are extremely complex and dynamic organizations. Doctors, clinicians, staff, patients and equipment are constantly moving around; hospitals must comply with a range of strict regulations and there are periods of high stress and life-and-death decisions. This requires a highly reliable communication infrastructure. At the same time, there is constant pressure on hospital IT administrators to lower costs while continuing to improve the level of patient care and satisfaction.
In this environment, hospitals are increasingly looking at new and more advanced wireless technologies to operate more efficiently, support patient care and improve the patient experience.
5.4.2 Cardiac telemetry inside hospital/care facility
5.4.2.1 Description
Basically, this is the same use case as described in clause 5.5.3 "Cardiac telemetry outside the hospital", with only a few minor adaptations.
Same as the description in clause 5.5.3.1.
5.4.2.2 Pre-conditions
Same as the pre-conditions in clause 5.5.3.2, but now the patient stays in the hospital (at the general ward) for a while, or resides in a care facility for a period of time. Furthermore, the hospital or care facility may be equipped with a non-public network and/or may use multi-RAT technologies (e.g. in-hospital Wi-Fi) that may be used to connect to the 5G core network.
5.4.2.3 Service Flows
Same as the service flows in clause 5.5.3.3, but now the patient stays in the hospital for a while initially, or resides in a care facility for a period of time instead of his own apartment. He can freely move around the hospital and is stimulated to do so, since physical activity aids in his recovery. The nursing staff is able to continuously keep track of the patient's condition due to the wireless ECG telemetry device that he is wearing.
5.4.2.4 Post-conditions
Same as the post-conditions in clause 5.5.3.4.
5.4.2.5 Existing features partly or fully covering the use case functionality
Reference number
Requirement text
Application / Transport
Comment
6.3 All requirements related to multiple access technologies, including non-3GPP access technologies such as Wi-Fi. T See TS 22.261
6.25 All requirements related to non-public networks. T See TS 22.261
Other existing features are the same as in clause 5.5.3.5.
5.4.2.6 Potential New Requirements needed to support the use case Word‑p. 43
Inside the hospital the reliability of the communication is expected (and targeted) in general to be higher than the reliability when devices are deployed outside of the hospital (see clause 5.5.3; Table 5.5.3.6-1). The target performance requirements for inside the hospital are shown in Table 5.4.2.6-1.
Communication service availability: target value
Communication service reliability: mean time between failures
End-to-end latency: maximum
Service bit rate: user experienced data rate
Message size [byte]
Survival time
UE speed
# of active UEs
Service area
Remarks
99,99999 % > 1 year < 100 ms 0.5 Mbit/s ≤ 1000 100ms ≤ 5 km/h ≤ 1000 per km2 Hospital (incl. elevators)
-
Use case entails body-worn IoT device.
-
Use case involves possible deployment using non-public network and/or multi-RAT technologies (incl. handover to PLMN)
5.5 Moving - Remote Word‑p. 44
5.5.1 Description of Modality
This modality deals with remote health monitoring of patients in their daily life and with monitoring/providing continuous care to injured patients in a moving ambulance while they are being transported to the nearest hospital or other definitive care after they have been stabilized at the scene of the incident.
-
Remote health monitoring is growing in popularity as both patients and healthcare professionals prefer health to be monitored outside of clinical settings for both comfort and cost efficiency reasons. In general, it involves patient-worn monitoring solutions that give patients the freedom to move around, and that are connected to a central nursing area or hospital through a wireless 5G connection. In this context, the body-worn devices shall be able to function for long period of time on the same battery charge while the 5G network is expected to provide a ubiquitous connectivity from underground parking places or building basements to other radio adverse indoor locations such as elevators.
-
Monitoring/providing care to patients in a moving connected ambulance requires medical equipment and paramedics to be delivered with high priority 5G communication services with consistent performances along the path from the accident location to the care facility where the patient will receive definitive care. This is key to ensure the medical staff can get prepared to manage the patient adequately when he arrives at the hospital.
5.5.2 Patient monitoring inside ambulances
5.5.2.1 Description
Paramedics transporting patients to the hospital typically brief hospital staff once the ambulance arrives. But in a 5G-connected ambulance, emergency crews will be able to collect critical patient data and share it with the hospital in real time, even before they arrive. Emergency doctors and nurses will then be better prepared to receive the patient, which means a smoother, more efficient handover process.
Ambulance operations are an essential part of the emergency services and over the past few decades have become increasingly advanced, featuring a significant number of fairly high-tech medical equipment and devices. With the widespread roll-out of 5G wireless communications networks, however, these traditional ambulances could soon make way for 5G connected ambulances.
In practise, connected Ambulance will act as a connection hub for the emergency medical equipment and wearables, enabling storing and real-time streaming of patient data to the awaiting emergency department team at the destination hospital. The continuous collection and streaming of patient data will begin when the emergency ambulance paramedics arrive at the incident scene right up until the delivery of the patient to the emergency department at the destination hospital. It shall also be noted that all data streams shall be reasonably synchronised in order to be able to correlate monitoring events and images and to enable recording and offline synchronized playback of the intervention. This is achieved through the synchronisation of all equipment having 5G connectivity inside the ambulance (camera, microphone, medical systems …) on the same global clock provided by the 5G system.
Typically those connected ambulances, today usually equipped with echographers, could be equipped in the medium term with portable CT (Computed Tomography) and x-ray scanners, high definition video camera, or even portable MRI scanners so that doctors in the Emergency Room Centre (ERC) can 'see' the patient via high definition visual connection and for example order a CT scan of the patient's head.
The 5G connection shall be reliable, stable and in a conservative approach we mandate all medical data to be transmitted with a high priority and with a very low probability to consecutively violate service defined constraints for the duration of the journey to the hospital.
5.5.2.2 Pre-conditions
There has been important car accident on the M11 North East of London close to Coopersale exit at the end of the afternoon (5pm). Involved vehicles are obstructing the traffic thus rapidly leading to severe congestion and long waiting times.
Sue is returning home after her working day and is driving over the speed limit at this location. When she realizes that all vehicles in front of her are all stopped on the road, she hits the brakes. Her car goes onto a skid and onto the unimproved shoulder and rolls over. In this process Sue hits her head on the windshield and passes out.
People that are witnessing the scene call the London Ambulance Service that decides to dispatch a connected ambulance on site. The Emergency Room Center (ERC) and a local MNO have a business contract in place by which the ERC can ask the MNO (through suitable APIs) to allocate the necessary high priority resources fulfilling SLAs suitable to the transport of medical data (with special care taken on medical data integrity and confidentiality) over a geographical area covering the site of the accident and the route from that site to the hospital.
Each needed equipment in the connected ambulance (ultrasound probe, monitoring scopes, CT and X-Ray scanners…) is:
-
Powered up,
-
Subscribed to 5G communication services fulfilling agreed SLAs,
-
Attached to the local MNO 5G network,
-
Provisioned with parameters allowing establishment of a secure communication link to an authenticated application in the ERC and/or hospital in charge of sharing incident data with the authorized personnel
5.5.2.3 Service Flows Word‑p. 45
With his connected ambulance, Fred the paramedic arrives at the accident's site and finds Sue in her car, still unconscious. Fred rapidly assesses the situation and based on the fact that traumatic brain injuries are usually emergencies with consequences that can worsen rapidly without treatment, decides to take Sue to the nearest hospital as quickly as possible.
-
In the connected ambulance, a UHD video camera captures a 4K video of the ambulance interiors continuously, while an audio system enables EVS full band voice communication with the remote ERC. The video (a stream of 3840x2160 pixels encoded using 12 bits per pixel color coding (e.g. YUV 4:1:1 [28]) with a framerate up to 60 fps and compressed with lossy compression algorithm) and the audio stream (up to 128 kbps) are relayed by the ambulance to the ERC.
-
Once in the ambulance, Sue regains consciousness and Fred can then perform the 15-point test to assess Sue's brain injury severity (checking a person's ability to follow directions, move their eyes and limbs and to answer questions). Sue is scored 9 on Glasgow Coma scale, meaning she is suffering from severe brain trauma.
-
Fred puts ECG electrodes on Sue's chest, arms and legs and positions also additional sensors in order to monitor a number of other physical vital signs (body temperature, blood pressure …). The resulting <1 Mbps data stream is relayed over a high priority 5G data stream to the emergency room.
-
Sue passes out again and her ECG starts showing arrhythmias. Fred, decides to execute a CT scan using the portable equipment in the ambulance, in order to create a detailed view of her brain and visualize potential fractures, evidence of bleeding, blood clots or bruised brain tissue. The equipment starts generating a 10 fps 2048x2048 stream of images with 12 to 16 bits per pixel color depth that is relayed to the ERC over a 5G high priority connection.
-
Based on received CT images, remote doctors warns Fred's that bleeding in the brain is resulting in a collection of clotted blood (hematoma) that is putting pressure in Sue's skull and is further damaging her brain tissue. Fortunately, the bleed location is precisely determined and a simple aspiration procedure looks feasible.
-
Under voice guidance from a remote specialist that has real time access to the scene inside the ambulance, Fred drills a small hole into Sue's skull and drains the hematoma using a needle. As he can't remove the hematoma completely nor stop the bleeding, he then inserts a probe in order to monitor her pressure continuously and to stream pressure data over the 5G secure connection to the ERC.
-
Upon arrival at the hospital, the staff is waiting and has all needed data to proceed with the emergency surgery in the prepared OR. Sue is rushed there for immediate surgery.
-
Resources assigned for the communication services allocated to the ambulance are released by the MNO.
5.5.2.4 Post-conditions
Sue undergoes an emergency surgery consisting in opening a window in her skull to provide more room for swollen tissues and to relieve pressure from accumulated blood and cerebral spinal fluid.
After the surgery, she recovers rapidly and returns back home after a couple of weeks of observation at the hospital.
5.5.2.5 Existing features partly or fully covering the use case functionality Word‑p. 46
Reference number
Requirement text
Application / Transport
Comment
8.9 The 5G system shall support data integrity protection and confidentiality methods that serve URLLC and energy constrained devices. T See TS 22.261 \xbind.c#6.1.2:22.261
6.1.2 All requirements related to slice management, access, capacity, quality of service.
In particular, on prioritization of certain slices against others:
The 5G system shall enable the network operator to define a priority order between different network slices in case multiple network slices compete for resources on the same network. T See TS 22.261
6.10.2, 6.1.2.3 All requirements related to private slice management, access, limitation to a specific geographical area, isolation and fault tolerance. T See TS 22.261
8.2, 8.3 All requirements related to security management in private slices T See TS 22.261
6.2.3 The 5G system shall enable packet loss to be minimized during inter- and/or intra-access technology changes for some or all connections associated with a UE. T See TS 22.261
6.2.3 The 5G system shall minimize interruption time during inter- and/or intra- access technology mobility for some or all connections associated with a UE. T See TS 22.261
5.6.1, 5.6.2 Clock synchronization service level requirements related to global clock domain management, Clock synchronization service performance requirements (accuracy level 1) T See TS 22.104
5.5.2.6 Potential New Requirements needed to support the use case Word‑p. 47
Use case
Characteristic parameter
Influence quantity
5.5.2 - Patient monitoring inside ambulances
Communication service availability: target value in %
Communication service reliability: Mean Time Between Failure
End-to-end latency: maximum
Bit rate
Direction
Message Size [byte]
Survival time
UE speed
# of active UEs
Service Area [km] (note 3)
Compressed 4K (3840x2160 pixels) 12 bits per pixel (e.g. YUV4:1:1) 60 fps real time video stream 99.99 >1 month < 100ms 25 Mbits/s UE to Network ~1500 ~100 ms 150 <20 per 100 km2 <50 Uncompressed 2048x2048 pixels 16 bits per pixel 10 fps real-time video scan stream 99.999 >>1 month (<1 year) <100ms 670 Mbits/s UE to Network ~1500 ~100 ms 150 <20 per 100 km2 <50 Physical vital signs monitoring data stream 99.999 >>1 month (<1 year) <100 ms 1 Mbits/s UE to Network ~80 (note 1) 150 <20 per 100 km2 <50 High quality audio stream 99.99 >1 month <100 ms 128 kbits/s UE to Network; Network to UE ~300 (note 2) ~16 ms 150 <20 per 100 km2 <50
NOTE 1:
For example, 10 bytes digitized ECG signal sampled at 200Hz, plus 40 bytes IPv6 headers or 20 Bytes IPv4 headers + 22 bytes Ethernet + 4 bytes CRC
NOTE 2:
For example, 12 bytes RTP + 8 bytes UDP + 20 bytes IPv4 + 22 bytes Ethernet + 4 bytes CRC + Audio Payload = 322 bytes every 16ms
NOTE 3:
Straight line distance between an ambulance and the closest emergency room
5.5.3 Cardiac telemetry outside the hospital Word‑p. 48
5.5.3.1 Description
This use case focuses on the use of a wireless wearable telemetry device which includes on-body sensors to provide continuous ECG, Respiratory Rate and SpO2 monitoring while the patient remains active without the restriction of being attached to a bedside cardiac monitor.
Future healthcare will increasingly use on-body sensors, combined with real-time analytics to safeguard people's health. For example, if a person just had a heart attack or a known severe heart condition, it is necessary to continuously monitor the electrical activity of the person's heart, using an electrocardiogram (ECG). It would be helpful if such person could, after a short stay in the hospital, could be sent home as soon as possible by providing this person with a wearable telemetry device which has a very reliable always-on connection with the hospital and with sufficient safeguards that if something happens (e.g. another heart attack) that this person gets emergency assistance as soon as possible.
Since telemetry will be provided by a wearable device that needs to be worn 24/7, possibly for weeks or months, the device needs to be unobtrusive, lightweight, and have a small form factor. This may limit the types of batteries that could be used for such devices, but even so, recharging of the batteries is cumbersome and should be avoided. Also the peak power may be limited. Therefore, a wireless wearable telemetry device typically falls in the category of CIoT UEs.
5.5.3.2 Pre-conditions
In this use case, Paul is a patient that recently had a cardiac arrest and was brought to the hospital. After undergoing a bypass surgery, and recovering a few days in the intensive care unit, he is feeling a lot better. Due to Paul's weight problem and other medical conditions, the doctors are still a bit worried and would like to monitor his heart for a longer period of time. Together with Paul they decide that he does not need to stay in the hospital anymore and can go home as long as he continuously wears the telemetry device that they give to him, and that they will monitor his health from a distance and check once in a while with him through remote consultation.
5.5.3.3 Service Flows
-
A telemetry device is provided to Paul, and provisioned with all the necessary information to connect to the 5G network and the backend system (e.g. cloud service provided by the hospital) to which the telemetry data will securely be sent. After attaching the ECG leads/sensors, the telemetry device is switched on and automatically establishes a connection with the 5G network and to the backend system.
-
Paul says goodbye to the hospital staff, and leaves the hospital. He is driven to his home by taxi. All this time, the telemetry data is sent in real-time to the backend system, with no noticeable interruption when the telemetry device switches between base stations during his taxi ride.
-
Paul lives in a huge apartment building on the 15th floor. Even high up in the building, in the parking garage under the building and in the elevator the telemetry data connection works without interruption whilst maintaining a low peak power and without unnecessarily draining the battery.
-
Three weeks later he goes back to the hospital for a medical check-up. The physician says his health has improved a lot and he should start doing some physical exercises to further improve his health. The physician advises him to follow a health improvement program and is given another device, a simple body worn health sensor that will keep track of his physical activity, heart rate and respiratory rate for a long period of time whilst he participates in the health improvement program. For safety precaution, the device is configured such that if his heart stops, the device will issue an emergency call to 911 and include medical identity information that can be used by the 911 dispatcher to quickly access information about Paul's medical condition.
-
Paul is very happy with the news and when he reaches his apartment building, he is so enthusiastic that he decides to take the stairs to his apartment instead of the elevator. Unfortunately, his heart was not prepared for this. Paul collapses and he has another heart attack. Luckily, the sensor device that he was given automatically issues an emergency call to 911 on behalf of Paul. Using the accurate location information and the medical identity information that the 911 dispatcher received as part of the call, they quickly managed to get the ambulance and first responders to help Paul and save his life.
5.5.3.4 Post-conditions Word‑p. 49
After Paul is sent home from the hospital, Paul's heart condition is monitored 24/7. The real-time performance, reliability, security, service availability and handover performance provided by the 5G system and the battery usage on the telemetry device meets all requirements for the healthcare providers to fully trust the solution. This includes deployment in rural areas and deep indoor, e.g. inside apartment building. In case something happens he will get swift medical assistance.
5.5.3.5 Existing features partly or fully covering the use case functionality
Reference number
Requirement text
Application / Transport
Comment
8.9 The 5G system shall support data integrity protection and confidentiality methods that serve URLLC and energy constrained devices. T See TS 22.261
6.1.2 All requirements related to slice management, access, capacity, quality of service. T See TS 22.261
6.2.3 The 5G system shall enable packet loss to be minimized during inter- and/or intra- access technology changes for some or all connections associated with a UE. T See TS 22.261
6.2.3 The 5G system shall minimize interruption time during inter- and/or intra- access technology mobility for some or all connections associated with a UE. T See TS 22.261
6.27 All requirements related to positioning services T See TS 22.261
7.3 All performance requirements related to high accuracy positioning T See TS 22.261
10 Service requirements related to emergency calls A See TS 22.101
5.5.3.6 Potential New Requirements needed to support the use case Word‑p. 50
The 5G system shall support the following service performance requirements for IoT devices
Communication service availability: target value
Communication service reliability: mean time between failures
End-to-end latency: maximum
Service bit rate: user experienced data rate
Message size [byte]
Survival time
UE speed
# of active UEs
Service area
Remarks
99,9999 % below 1 year but >> 1 month < 100 ms 0.5 Mbit/s ≤ 1000 < 1s ≤ 500 km/h
-
In area with hospital up to 1000 per km2
-
In suburban areas up to 10 per km2
Country wide including rural areas and deep indoor. (see Note 1)
-
Use case entails body-worn IoT device (see Note 2)
-
User could be moving by car or by train.
NOTE 1:
In this context, "deep indoor" term is meant to be places like e.g. elevators, building's basement, underground parking lot…
NOTE 2:
These performance requirements are aimed to be achieved using a 3.3V battery powered device with battery capacity <1000 mAh without recharging for at least 1 month, and whereby the peak current for transmit operations stays below 50mA.
The 5G system shall support a secure mechanism that allows medical identification information to be automatically provided as part of an emergency call.
5.4.1 Description of Modality
Hospitals are extremely complex and dynamic organizations. Doctors, clinicians, staff, patients and equipment are constantly moving around; hospitals must comply with a range of strict regulations and there are periods of high stress and life-and-death decisions. This requires a highly reliable communication infrastructure. At the same time, there is constant pressure on hospital IT administrators to lower costs while continuing to improve the level of patient care and satisfaction.
In this environment, hospitals are increasingly looking at new and more advanced wireless technologies to operate more efficiently, support patient care and improve the patient experience.
5.4.2 Cardiac telemetry inside hospital/care facility
5.4.2.1 Description
Basically, this is the same use case as described in clause 5.5.3 "Cardiac telemetry outside the hospital", with only a few minor adaptations.
Same as the description in clause 5.5.3.1.
5.4.2.2 Pre-conditions
Same as the pre-conditions in clause 5.5.3.2, but now the patient stays in the hospital (at the general ward) for a while, or resides in a care facility for a period of time. Furthermore, the hospital or care facility may be equipped with a non-public network and/or may use multi-RAT technologies (e.g. in-hospital Wi-Fi) that may be used to connect to the 5G core network.
5.4.2.3 Service Flows
Same as the service flows in clause 5.5.3.3, but now the patient stays in the hospital for a while initially, or resides in a care facility for a period of time instead of his own apartment. He can freely move around the hospital and is stimulated to do so, since physical activity aids in his recovery. The nursing staff is able to continuously keep track of the patient's condition due to the wireless ECG telemetry device that he is wearing.
5.4.2.4 Post-conditions
Same as the post-conditions in clause 5.5.3.4.
5.4.2.5 Existing features partly or fully covering the use case functionality
| Reference number | Requirement text | Application / Transport | Comment |
|---|---|---|---|
| 6.3 | All requirements related to multiple access technologies, including non-3GPP access technologies such as Wi-Fi. | T | See TS 22.261 |
| 6.25 | All requirements related to non-public networks. | T | See TS 22.261 |
Other existing features are the same as in clause 5.5.3.5.
5.4.2.6 Potential New Requirements needed to support the use case Word‑p. 43
Inside the hospital the reliability of the communication is expected (and targeted) in general to be higher than the reliability when devices are deployed outside of the hospital (see clause 5.5.3; Table 5.5.3.6-1). The target performance requirements for inside the hospital are shown in Table 5.4.2.6-1.
| Communication service availability: target value | Communication service reliability: mean time between failures | End-to-end latency: maximum | Service bit rate: user experienced data rate | Message size [byte] | Survival time | UE speed | # of active UEs | Service area | Remarks |
|---|---|---|---|---|---|---|---|---|---|
| 99,99999 % | > 1 year | < 100 ms | 0.5 Mbit/s | ≤ 1000 | 100ms | ≤ 5 km/h | ≤ 1000 per km2 | Hospital (incl. elevators) |
|
5.5.1 Description of Modality
This modality deals with remote health monitoring of patients in their daily life and with monitoring/providing continuous care to injured patients in a moving ambulance while they are being transported to the nearest hospital or other definitive care after they have been stabilized at the scene of the incident.
- Remote health monitoring is growing in popularity as both patients and healthcare professionals prefer health to be monitored outside of clinical settings for both comfort and cost efficiency reasons. In general, it involves patient-worn monitoring solutions that give patients the freedom to move around, and that are connected to a central nursing area or hospital through a wireless 5G connection. In this context, the body-worn devices shall be able to function for long period of time on the same battery charge while the 5G network is expected to provide a ubiquitous connectivity from underground parking places or building basements to other radio adverse indoor locations such as elevators.
- Monitoring/providing care to patients in a moving connected ambulance requires medical equipment and paramedics to be delivered with high priority 5G communication services with consistent performances along the path from the accident location to the care facility where the patient will receive definitive care. This is key to ensure the medical staff can get prepared to manage the patient adequately when he arrives at the hospital.
5.5.2 Patient monitoring inside ambulances
5.5.2.1 Description
Paramedics transporting patients to the hospital typically brief hospital staff once the ambulance arrives. But in a 5G-connected ambulance, emergency crews will be able to collect critical patient data and share it with the hospital in real time, even before they arrive. Emergency doctors and nurses will then be better prepared to receive the patient, which means a smoother, more efficient handover process.
Ambulance operations are an essential part of the emergency services and over the past few decades have become increasingly advanced, featuring a significant number of fairly high-tech medical equipment and devices. With the widespread roll-out of 5G wireless communications networks, however, these traditional ambulances could soon make way for 5G connected ambulances.
In practise, connected Ambulance will act as a connection hub for the emergency medical equipment and wearables, enabling storing and real-time streaming of patient data to the awaiting emergency department team at the destination hospital. The continuous collection and streaming of patient data will begin when the emergency ambulance paramedics arrive at the incident scene right up until the delivery of the patient to the emergency department at the destination hospital. It shall also be noted that all data streams shall be reasonably synchronised in order to be able to correlate monitoring events and images and to enable recording and offline synchronized playback of the intervention. This is achieved through the synchronisation of all equipment having 5G connectivity inside the ambulance (camera, microphone, medical systems …) on the same global clock provided by the 5G system.
Typically those connected ambulances, today usually equipped with echographers, could be equipped in the medium term with portable CT (Computed Tomography) and x-ray scanners, high definition video camera, or even portable MRI scanners so that doctors in the Emergency Room Centre (ERC) can 'see' the patient via high definition visual connection and for example order a CT scan of the patient's head.
The 5G connection shall be reliable, stable and in a conservative approach we mandate all medical data to be transmitted with a high priority and with a very low probability to consecutively violate service defined constraints for the duration of the journey to the hospital.
5.5.2.2 Pre-conditions
There has been important car accident on the M11 North East of London close to Coopersale exit at the end of the afternoon (5pm). Involved vehicles are obstructing the traffic thus rapidly leading to severe congestion and long waiting times.
Sue is returning home after her working day and is driving over the speed limit at this location. When she realizes that all vehicles in front of her are all stopped on the road, she hits the brakes. Her car goes onto a skid and onto the unimproved shoulder and rolls over. In this process Sue hits her head on the windshield and passes out.
People that are witnessing the scene call the London Ambulance Service that decides to dispatch a connected ambulance on site. The Emergency Room Center (ERC) and a local MNO have a business contract in place by which the ERC can ask the MNO (through suitable APIs) to allocate the necessary high priority resources fulfilling SLAs suitable to the transport of medical data (with special care taken on medical data integrity and confidentiality) over a geographical area covering the site of the accident and the route from that site to the hospital.
Each needed equipment in the connected ambulance (ultrasound probe, monitoring scopes, CT and X-Ray scanners…) is:
- Powered up,
- Subscribed to 5G communication services fulfilling agreed SLAs,
- Attached to the local MNO 5G network,
- Provisioned with parameters allowing establishment of a secure communication link to an authenticated application in the ERC and/or hospital in charge of sharing incident data with the authorized personnel
5.5.2.3 Service Flows Word‑p. 45
With his connected ambulance, Fred the paramedic arrives at the accident's site and finds Sue in her car, still unconscious. Fred rapidly assesses the situation and based on the fact that traumatic brain injuries are usually emergencies with consequences that can worsen rapidly without treatment, decides to take Sue to the nearest hospital as quickly as possible.
-
In the connected ambulance, a UHD video camera captures a 4K video of the ambulance interiors continuously, while an audio system enables EVS full band voice communication with the remote ERC. The video (a stream of 3840x2160 pixels encoded using 12 bits per pixel color coding (e.g. YUV 4:1:1 [28]) with a framerate up to 60 fps and compressed with lossy compression algorithm) and the audio stream (up to 128 kbps) are relayed by the ambulance to the ERC.
-
Once in the ambulance, Sue regains consciousness and Fred can then perform the 15-point test to assess Sue's brain injury severity (checking a person's ability to follow directions, move their eyes and limbs and to answer questions). Sue is scored 9 on Glasgow Coma scale, meaning she is suffering from severe brain trauma.
-
Fred puts ECG electrodes on Sue's chest, arms and legs and positions also additional sensors in order to monitor a number of other physical vital signs (body temperature, blood pressure …). The resulting <1 Mbps data stream is relayed over a high priority 5G data stream to the emergency room.
-
Sue passes out again and her ECG starts showing arrhythmias. Fred, decides to execute a CT scan using the portable equipment in the ambulance, in order to create a detailed view of her brain and visualize potential fractures, evidence of bleeding, blood clots or bruised brain tissue. The equipment starts generating a 10 fps 2048x2048 stream of images with 12 to 16 bits per pixel color depth that is relayed to the ERC over a 5G high priority connection.
-
Based on received CT images, remote doctors warns Fred's that bleeding in the brain is resulting in a collection of clotted blood (hematoma) that is putting pressure in Sue's skull and is further damaging her brain tissue. Fortunately, the bleed location is precisely determined and a simple aspiration procedure looks feasible.
-
Under voice guidance from a remote specialist that has real time access to the scene inside the ambulance, Fred drills a small hole into Sue's skull and drains the hematoma using a needle. As he can't remove the hematoma completely nor stop the bleeding, he then inserts a probe in order to monitor her pressure continuously and to stream pressure data over the 5G secure connection to the ERC.
-
Upon arrival at the hospital, the staff is waiting and has all needed data to proceed with the emergency surgery in the prepared OR. Sue is rushed there for immediate surgery.
-
Resources assigned for the communication services allocated to the ambulance are released by the MNO.
5.5.2.4 Post-conditions
Sue undergoes an emergency surgery consisting in opening a window in her skull to provide more room for swollen tissues and to relieve pressure from accumulated blood and cerebral spinal fluid.
After the surgery, she recovers rapidly and returns back home after a couple of weeks of observation at the hospital.
5.5.2.5 Existing features partly or fully covering the use case functionality Word‑p. 46
- In the connected ambulance, a UHD video camera captures a 4K video of the ambulance interiors continuously, while an audio system enables EVS full band voice communication with the remote ERC. The video (a stream of 3840x2160 pixels encoded using 12 bits per pixel color coding (e.g. YUV 4:1:1 [28]) with a framerate up to 60 fps and compressed with lossy compression algorithm) and the audio stream (up to 128 kbps) are relayed by the ambulance to the ERC.
- Once in the ambulance, Sue regains consciousness and Fred can then perform the 15-point test to assess Sue's brain injury severity (checking a person's ability to follow directions, move their eyes and limbs and to answer questions). Sue is scored 9 on Glasgow Coma scale, meaning she is suffering from severe brain trauma.
- Fred puts ECG electrodes on Sue's chest, arms and legs and positions also additional sensors in order to monitor a number of other physical vital signs (body temperature, blood pressure …). The resulting <1 Mbps data stream is relayed over a high priority 5G data stream to the emergency room.
- Sue passes out again and her ECG starts showing arrhythmias. Fred, decides to execute a CT scan using the portable equipment in the ambulance, in order to create a detailed view of her brain and visualize potential fractures, evidence of bleeding, blood clots or bruised brain tissue. The equipment starts generating a 10 fps 2048x2048 stream of images with 12 to 16 bits per pixel color depth that is relayed to the ERC over a 5G high priority connection.
- Based on received CT images, remote doctors warns Fred's that bleeding in the brain is resulting in a collection of clotted blood (hematoma) that is putting pressure in Sue's skull and is further damaging her brain tissue. Fortunately, the bleed location is precisely determined and a simple aspiration procedure looks feasible.
- Under voice guidance from a remote specialist that has real time access to the scene inside the ambulance, Fred drills a small hole into Sue's skull and drains the hematoma using a needle. As he can't remove the hematoma completely nor stop the bleeding, he then inserts a probe in order to monitor her pressure continuously and to stream pressure data over the 5G secure connection to the ERC.
- Upon arrival at the hospital, the staff is waiting and has all needed data to proceed with the emergency surgery in the prepared OR. Sue is rushed there for immediate surgery.
- Resources assigned for the communication services allocated to the ambulance are released by the MNO.
| Reference number | Requirement text | Application / Transport | Comment |
|---|---|---|---|
| 8.9 | The 5G system shall support data integrity protection and confidentiality methods that serve URLLC and energy constrained devices. | T | See TS 22.261 |
| \xbind.c#6.1.2:22.261 6.1.2 | All requirements related to slice management, access, capacity, quality of service. In particular, on prioritization of certain slices against others: The 5G system shall enable the network operator to define a priority order between different network slices in case multiple network slices compete for resources on the same network. | T | See TS 22.261 |
| 6.10.2, 6.1.2.3 | All requirements related to private slice management, access, limitation to a specific geographical area, isolation and fault tolerance. | T | See TS 22.261 |
| 8.2, 8.3 | All requirements related to security management in private slices | T | See TS 22.261 |
| 6.2.3 | The 5G system shall enable packet loss to be minimized during inter- and/or intra-access technology changes for some or all connections associated with a UE. | T | See TS 22.261 |
| 6.2.3 | The 5G system shall minimize interruption time during inter- and/or intra- access technology mobility for some or all connections associated with a UE. | T | See TS 22.261 |
| 5.6.1, 5.6.2 | Clock synchronization service level requirements related to global clock domain management, Clock synchronization service performance requirements (accuracy level 1) | T | See TS 22.104 |
5.5.2.6 Potential New Requirements needed to support the use case Word‑p. 47
| Use case | Characteristic parameter | Influence quantity | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 5.5.2 - Patient monitoring inside ambulances | Communication service availability: target value in % | Communication service reliability: Mean Time Between Failure | End-to-end latency: maximum | Bit rate | Direction | Message Size [byte] | Survival time | UE speed | # of active UEs | Service Area [km] (note 3) |
| Compressed 4K (3840x2160 pixels) 12 bits per pixel (e.g. YUV4:1:1) 60 fps real time video stream | 99.99 | >1 month | < 100ms | 25 Mbits/s | UE to Network | ~1500 | ~100 ms | 150 | <20 per 100 km2 | <50 |
| Uncompressed 2048x2048 pixels 16 bits per pixel 10 fps real-time video scan stream | 99.999 | >>1 month (<1 year) | <100ms | 670 Mbits/s | UE to Network | ~1500 | ~100 ms | 150 | <20 per 100 km2 | <50 |
| Physical vital signs monitoring data stream | 99.999 | >>1 month (<1 year) | <100 ms | 1 Mbits/s | UE to Network | ~80 (note 1) | 150 | <20 per 100 km2 | <50 | |
| High quality audio stream | 99.99 | >1 month | <100 ms | 128 kbits/s | UE to Network; Network to UE | ~300 (note 2) | ~16 ms | 150 | <20 per 100 km2 | <50 |
|
NOTE 1:
For example, 10 bytes digitized ECG signal sampled at 200Hz, plus 40 bytes IPv6 headers or 20 Bytes IPv4 headers + 22 bytes Ethernet + 4 bytes CRC
NOTE 2:
For example, 12 bytes RTP + 8 bytes UDP + 20 bytes IPv4 + 22 bytes Ethernet + 4 bytes CRC + Audio Payload = 322 bytes every 16ms
NOTE 3:
Straight line distance between an ambulance and the closest emergency room
|
||||||||||
5.5.3 Cardiac telemetry outside the hospital Word‑p. 48
5.5.3.1 Description
This use case focuses on the use of a wireless wearable telemetry device which includes on-body sensors to provide continuous ECG, Respiratory Rate and SpO2 monitoring while the patient remains active without the restriction of being attached to a bedside cardiac monitor.
Future healthcare will increasingly use on-body sensors, combined with real-time analytics to safeguard people's health. For example, if a person just had a heart attack or a known severe heart condition, it is necessary to continuously monitor the electrical activity of the person's heart, using an electrocardiogram (ECG). It would be helpful if such person could, after a short stay in the hospital, could be sent home as soon as possible by providing this person with a wearable telemetry device which has a very reliable always-on connection with the hospital and with sufficient safeguards that if something happens (e.g. another heart attack) that this person gets emergency assistance as soon as possible.
Since telemetry will be provided by a wearable device that needs to be worn 24/7, possibly for weeks or months, the device needs to be unobtrusive, lightweight, and have a small form factor. This may limit the types of batteries that could be used for such devices, but even so, recharging of the batteries is cumbersome and should be avoided. Also the peak power may be limited. Therefore, a wireless wearable telemetry device typically falls in the category of CIoT UEs.
5.5.3.2 Pre-conditions
In this use case, Paul is a patient that recently had a cardiac arrest and was brought to the hospital. After undergoing a bypass surgery, and recovering a few days in the intensive care unit, he is feeling a lot better. Due to Paul's weight problem and other medical conditions, the doctors are still a bit worried and would like to monitor his heart for a longer period of time. Together with Paul they decide that he does not need to stay in the hospital anymore and can go home as long as he continuously wears the telemetry device that they give to him, and that they will monitor his health from a distance and check once in a while with him through remote consultation.
5.5.3.3 Service Flows
-
A telemetry device is provided to Paul, and provisioned with all the necessary information to connect to the 5G network and the backend system (e.g. cloud service provided by the hospital) to which the telemetry data will securely be sent. After attaching the ECG leads/sensors, the telemetry device is switched on and automatically establishes a connection with the 5G network and to the backend system.
-
Paul says goodbye to the hospital staff, and leaves the hospital. He is driven to his home by taxi. All this time, the telemetry data is sent in real-time to the backend system, with no noticeable interruption when the telemetry device switches between base stations during his taxi ride.
-
Paul lives in a huge apartment building on the 15th floor. Even high up in the building, in the parking garage under the building and in the elevator the telemetry data connection works without interruption whilst maintaining a low peak power and without unnecessarily draining the battery.
-
Three weeks later he goes back to the hospital for a medical check-up. The physician says his health has improved a lot and he should start doing some physical exercises to further improve his health. The physician advises him to follow a health improvement program and is given another device, a simple body worn health sensor that will keep track of his physical activity, heart rate and respiratory rate for a long period of time whilst he participates in the health improvement program. For safety precaution, the device is configured such that if his heart stops, the device will issue an emergency call to 911 and include medical identity information that can be used by the 911 dispatcher to quickly access information about Paul's medical condition.
-
Paul is very happy with the news and when he reaches his apartment building, he is so enthusiastic that he decides to take the stairs to his apartment instead of the elevator. Unfortunately, his heart was not prepared for this. Paul collapses and he has another heart attack. Luckily, the sensor device that he was given automatically issues an emergency call to 911 on behalf of Paul. Using the accurate location information and the medical identity information that the 911 dispatcher received as part of the call, they quickly managed to get the ambulance and first responders to help Paul and save his life.
5.5.3.4 Post-conditions Word‑p. 49
After Paul is sent home from the hospital, Paul's heart condition is monitored 24/7. The real-time performance, reliability, security, service availability and handover performance provided by the 5G system and the battery usage on the telemetry device meets all requirements for the healthcare providers to fully trust the solution. This includes deployment in rural areas and deep indoor, e.g. inside apartment building. In case something happens he will get swift medical assistance.
5.5.3.5 Existing features partly or fully covering the use case functionality
Reference number
Requirement text
Application / Transport
Comment
8.9 The 5G system shall support data integrity protection and confidentiality methods that serve URLLC and energy constrained devices. T See TS 22.261
6.1.2 All requirements related to slice management, access, capacity, quality of service. T See TS 22.261
6.2.3 The 5G system shall enable packet loss to be minimized during inter- and/or intra- access technology changes for some or all connections associated with a UE. T See TS 22.261
6.2.3 The 5G system shall minimize interruption time during inter- and/or intra- access technology mobility for some or all connections associated with a UE. T See TS 22.261
6.27 All requirements related to positioning services T See TS 22.261
7.3 All performance requirements related to high accuracy positioning T See TS 22.261
10 Service requirements related to emergency calls A See TS 22.101
5.5.3.6 Potential New Requirements needed to support the use case Word‑p. 50
The 5G system shall support the following service performance requirements for IoT devices
Communication service availability: target value
Communication service reliability: mean time between failures
End-to-end latency: maximum
Service bit rate: user experienced data rate
Message size [byte]
Survival time
UE speed
# of active UEs
Service area
Remarks
99,9999 % below 1 year but >> 1 month < 100 ms 0.5 Mbit/s ≤ 1000 < 1s ≤ 500 km/h
-
In area with hospital up to 1000 per km2
-
In suburban areas up to 10 per km2
Country wide including rural areas and deep indoor. (see Note 1)
-
Use case entails body-worn IoT device (see Note 2)
-
User could be moving by car or by train.
NOTE 1:
In this context, "deep indoor" term is meant to be places like e.g. elevators, building's basement, underground parking lot…
NOTE 2:
These performance requirements are aimed to be achieved using a 3.3V battery powered device with battery capacity <1000 mAh without recharging for at least 1 month, and whereby the peak current for transmit operations stays below 50mA.
The 5G system shall support a secure mechanism that allows medical identification information to be automatically provided as part of an emergency call.
5.5.3.1 Description
This use case focuses on the use of a wireless wearable telemetry device which includes on-body sensors to provide continuous ECG, Respiratory Rate and SpO2 monitoring while the patient remains active without the restriction of being attached to a bedside cardiac monitor.
Future healthcare will increasingly use on-body sensors, combined with real-time analytics to safeguard people's health. For example, if a person just had a heart attack or a known severe heart condition, it is necessary to continuously monitor the electrical activity of the person's heart, using an electrocardiogram (ECG). It would be helpful if such person could, after a short stay in the hospital, could be sent home as soon as possible by providing this person with a wearable telemetry device which has a very reliable always-on connection with the hospital and with sufficient safeguards that if something happens (e.g. another heart attack) that this person gets emergency assistance as soon as possible.
Since telemetry will be provided by a wearable device that needs to be worn 24/7, possibly for weeks or months, the device needs to be unobtrusive, lightweight, and have a small form factor. This may limit the types of batteries that could be used for such devices, but even so, recharging of the batteries is cumbersome and should be avoided. Also the peak power may be limited. Therefore, a wireless wearable telemetry device typically falls in the category of CIoT UEs.
5.5.3.2 Pre-conditions
In this use case, Paul is a patient that recently had a cardiac arrest and was brought to the hospital. After undergoing a bypass surgery, and recovering a few days in the intensive care unit, he is feeling a lot better. Due to Paul's weight problem and other medical conditions, the doctors are still a bit worried and would like to monitor his heart for a longer period of time. Together with Paul they decide that he does not need to stay in the hospital anymore and can go home as long as he continuously wears the telemetry device that they give to him, and that they will monitor his health from a distance and check once in a while with him through remote consultation.
5.5.3.3 Service Flows
- A telemetry device is provided to Paul, and provisioned with all the necessary information to connect to the 5G network and the backend system (e.g. cloud service provided by the hospital) to which the telemetry data will securely be sent. After attaching the ECG leads/sensors, the telemetry device is switched on and automatically establishes a connection with the 5G network and to the backend system.
- Paul says goodbye to the hospital staff, and leaves the hospital. He is driven to his home by taxi. All this time, the telemetry data is sent in real-time to the backend system, with no noticeable interruption when the telemetry device switches between base stations during his taxi ride.
- Paul lives in a huge apartment building on the 15th floor. Even high up in the building, in the parking garage under the building and in the elevator the telemetry data connection works without interruption whilst maintaining a low peak power and without unnecessarily draining the battery.
- Three weeks later he goes back to the hospital for a medical check-up. The physician says his health has improved a lot and he should start doing some physical exercises to further improve his health. The physician advises him to follow a health improvement program and is given another device, a simple body worn health sensor that will keep track of his physical activity, heart rate and respiratory rate for a long period of time whilst he participates in the health improvement program. For safety precaution, the device is configured such that if his heart stops, the device will issue an emergency call to 911 and include medical identity information that can be used by the 911 dispatcher to quickly access information about Paul's medical condition.
- Paul is very happy with the news and when he reaches his apartment building, he is so enthusiastic that he decides to take the stairs to his apartment instead of the elevator. Unfortunately, his heart was not prepared for this. Paul collapses and he has another heart attack. Luckily, the sensor device that he was given automatically issues an emergency call to 911 on behalf of Paul. Using the accurate location information and the medical identity information that the 911 dispatcher received as part of the call, they quickly managed to get the ambulance and first responders to help Paul and save his life.
5.5.3.4 Post-conditions Word‑p. 49
After Paul is sent home from the hospital, Paul's heart condition is monitored 24/7. The real-time performance, reliability, security, service availability and handover performance provided by the 5G system and the battery usage on the telemetry device meets all requirements for the healthcare providers to fully trust the solution. This includes deployment in rural areas and deep indoor, e.g. inside apartment building. In case something happens he will get swift medical assistance.
5.5.3.5 Existing features partly or fully covering the use case functionality
| Reference number | Requirement text | Application / Transport | Comment |
|---|---|---|---|
| 8.9 | The 5G system shall support data integrity protection and confidentiality methods that serve URLLC and energy constrained devices. | T | See TS 22.261 |
| 6.1.2 | All requirements related to slice management, access, capacity, quality of service. | T | See TS 22.261 |
| 6.2.3 | The 5G system shall enable packet loss to be minimized during inter- and/or intra- access technology changes for some or all connections associated with a UE. | T | See TS 22.261 |
| 6.2.3 | The 5G system shall minimize interruption time during inter- and/or intra- access technology mobility for some or all connections associated with a UE. | T | See TS 22.261 |
| 6.27 | All requirements related to positioning services | T | See TS 22.261 |
| 7.3 | All performance requirements related to high accuracy positioning | T | See TS 22.261 |
| 10 | Service requirements related to emergency calls | A | See TS 22.101 |
5.5.3.6 Potential New Requirements needed to support the use case Word‑p. 50
The 5G system shall support the following service performance requirements for IoT devices
| Communication service availability: target value | Communication service reliability: mean time between failures | End-to-end latency: maximum | Service bit rate: user experienced data rate | Message size [byte] | Survival time | UE speed | # of active UEs | Service area | Remarks |
|---|---|---|---|---|---|---|---|---|---|
| 99,9999 % | below 1 year but >> 1 month | < 100 ms | 0.5 Mbit/s | ≤ 1000 | < 1s | ≤ 500 km/h |
| Country wide including rural areas and deep indoor. (see Note 1) |
|
|
NOTE 1:
In this context, "deep indoor" term is meant to be places like e.g. elevators, building's basement, underground parking lot…
NOTE 2:
These performance requirements are aimed to be achieved using a 3.3V battery powered device with battery capacity <1000 mAh without recharging for at least 1 month, and whereby the peak current for transmit operations stays below 50mA.
|
|||||||||
The 5G system shall support a secure mechanism that allows medical identification information to be automatically provided as part of an emergency call.
