IEEE 11073 20401

qualtaghblurtingΚινητά – Ασύρματες Τεχνολογίες

12 Δεκ 2013 (πριν από 3 χρόνια και 9 μήνες)

117 εμφανίσεις

11073
-
20401
-
20130504.pptx


SLIDE
1

IEEE 11073 20401

Application Profile
-

Common Network
Services



Vivek Kamath, vpkamath@westhealth.org

11073
-
20401
-
20130504.pptx


SLIDE
2

IEEE 11073
-
20401 Project (PAR) Scope:

Within the framework of IEEE 11073
standards, this standard will define a
common, transport neutral set
of
networking
services that will enable plug
-
and
-
play interoperability of medical
devices.

This project shall not address quality of
service over RF wireless network
connections.

11073
-
20401
-
20130504.pptx


SLIDE
3

Scope Summary:


Define common set of networking services



Transport Neutral



Enable plug
-
and
-
play



For medical devices

11073
-
20401
-
20130504.pptx


SLIDE
4

Aspects of CNS


Defines functional, architectural,
topological framework to standardize
network semantics for networked
medical
devices


Enables profiling of clinical scenarios from
communication perspective.


Defines
Transport Independent System
Layer ( TISL) as a standard interface to
upper layers



11073
-
20401
-
20130504.pptx


SLIDE
5

11073
-
20401
-
20130504.pptx


SLIDE
6

Transport Stack Overview

ethernet



11073

“upper layers”



Wi
-
Fi

Cellular Data

Wi
-
Max

802.3

10/100/

1000BT

802.11

RF

GPRS

EDGE

1xRTT

4G /LTE

RF

802.16

RF

IP

RTP

TCP

UDP

SCTP

IrLAP

IR

IrLMP

TinyTP

RS
-
232

IP Support Services

11073 config
service

11073 assoc
service

DHCP

DNS

Net.
capacity
service

LDAP

NTP

Radius

Location
services

Presence
services

SNMP

802.1x

NAT

USB

BlueTooth

PHDC

MDP

current

s
hort term

point to point links

short term

possible
future

IP centric links

USB

ether

class drv

BlueTooth

IP

profile

MICS

WMTS

ZigBee

possible
future

Interface to ‘upper
layers

-

TISL

11073
-
20401
-
20130504.pptx


SLIDE
7

Clinical Scenarios
-

ENV
13735 Annex
E 2.1

Scenario

Communication Requirements

Emergency Situation


One

of the main
scenarios is alarm
(2.1.1)

Plug and Play
-

the device communication must start
immediately after device connection without any

further user intervention. That implies e.g. automatic
device recognition, identification, and initialization of

communication.


Safety and reliability of communication and network
-

connection of a new device must not influence

the communication of other devices connected earlier


Unique device identification

Normal patient nursing
condition in ICU, non
emergency situations
(2.2)

Same as above

11073
-
20401
-
20130504.pptx


SLIDE
8

Application
Scenarios ENV 13735 Annex E 3

Scenario

Communication Requirements

Data Logger ( 3.1)

Graphic parameter data volumes can require high
bandwidth

‘Loose’ device time stamp synchronization, in the order of
0.01 second, is required.

Real Time Data
Display (3.2)

Latency of data between amplifier output and display on
screen must be less than 0.2 seconds to be invisible

for user.

Patient Alarm
Monitoring (3.3)

The communication of alarm related information must be
expedited, in order to be processed prior to

other data, and must be reliable.

Display Device must be able to detect when a Data Agent
is removed. Ideally it should be able to distinguish between
an intentional disconnection and unintentional
disconnection.

The latency of occurrence of alarm and signaling to user
must be less than 0.25 seconds.

11073
-
20401
-
20130504.pptx


SLIDE
9

Application Scenarios

Scenario

Communication Requirements

Remote Control (3.4)

In a remote control system, the communication must fulfill
a higher level of reliability, because of a higher

risk for the patient. This includes the needs for
comprehensive message validation, data verification,
message retries, and notification of communication system
failures. This implies the need for system management

functionality.

A mechanism to send control data to the data agent and
acknowledge receipt is required. In some cases

manual control of the device should be precluded.

Patient Viewing
Interoperability (3.5)

There must be some level of control such that a remote
user (i.e. outside the care unit) cannot change the

settings established by a nurse at the bedside.

Harmonization of communication methods for RF telemetry
systems would be required in order to support

interoperable telemetry systems.

Bandwidth management may become a big issue.

The issue of managing multiple associations between a
Data Agent and multiple Data Loggers or Data Dis
-

play needs attention.

11073
-
20401
-
20130504.pptx


SLIDE
10


Scenario

Communication Requirements

Patient Monitoring
Interoperability (3.6)

Communication over different hospital LANs

and maybe
even on the Internet.

Ordering of physiological data is important.

Latency from Data Agent to Remote Monitoring Device
must be controlled and specified. Generally, this

should be less than one second to be acceptable.

Maintenance

and
Configuration
Support

(3.8)

Physical connect/disconnect sensing for devices.

System management protocol

Intrabed

Symmetric
Data Exchange
between DCC and
BCC (4.1)


Interbed

Symmetric
Data Exchange over
an "
Interbed

Network“ (4.2)

Symmetry in communication between device (DCC) and
BCC

Symmetry in data propagation in through the BCC
-

from
device (DCC) through BCC to Application System

and vice versa

Propagation of a containment tree of a remote device to
the receiver (DCC)

11073
-
20401
-
20130504.pptx


SLIDE
11

CNS Framework

Use context

In
-
Patient (/Hospital)

Emerg/Evac

Home


Pt. Care Intensity level

Intensive

Intermediate (/StepDown)

Ward

Enterprise

"TeleHealth"


Nursing/Pt ratio

≥1

≤1

< 1
--------
Central
--------

<<1










Pt. Acuity range (Hi
--
>Lo)

Critical

Acute

Sub
-
Acute

General





Crit/Acute

Chronic




Scenario (EN13735 Apx.E)

2.1.1



2.2

3.1

































OR/ICU PoC







































OR

Emerg./Trauma































Instrument








































Modularity



Integr'd
--
>Component Modular


































Modality



[AnesMach.]































AHD

PHD


Pt.Mon

1

SCADA











[Trans
-
]
Portable



Pt. Worn




















Infusor

0
-
n

Syringe, LVP

PCA
































Vent

0
-
1

[Non
-
]Invasive
































. . .



[Port. Xray]


































Bed



Stationary

































Service
Typology








































Provision



RDC

HHT



























HHT





Pt. Admin

Pt:Dev ID Binding; Pt Transfer













[N]RT SCADA

RT Auto<
------
Semi
-
Auto
-------------------------

Remote Control [/Config]
------------------
> NRT Supervisory















Physio
Mon'g/Alarmin
g





DataLogging
1

SpotChecking

Inter
-
CU
Trf



Ambulating
(Intra
-
CU)



(CU<
----
>Ancillary)



NRT & Spot SCADA





NRT & Spot SCADA


Security



Limited









2

Moderate(Pt.; Dev.; User ID)


--
Centralize
d
--
>











Remote




Discov



Device <
--------------------

Association, Location
-----------------------
> Patient














QoS



Cts, VHiReliab















Cts, HiReliab


















Connectivity






































Topology

Local

NMS













Remote

RNMS












Technology



PAN



[w]PAN

[P/][w]LAN



[wPAN] (SRR)

P[w][L]AN



wLAN("tele")

wLAN









[w]WAN ("tele")

[w]P/LAN

Key:

HHT=Home
-
Hosp. Trf

1

May be "Gateway"ed

Instrumented Pt. Transfer types:

AHD = Appl'n Hosting Device

[N]RT = [Near] RealTime

PCA = Patient Controlled Analgesia


e.g. PACU
--
>ICU; CCU
--
>IICU

PHD = Personal Health Device[s]

SCADA = Sup'y Ctl & DataAcq'n

PACU = Post
-
Anesthesia Care Unit

2

==> if wless, then probably has link
-
level crypto

RDC = Rapid Dev Config

[R]NMS = [Remote] Net Mgmt Service

11073
-
20401
-
20130504.pptx


SLIDE
12

TISL Overview


Provides uniform interface to upper
layers


Has following
services


Discovery of services and devices


Connectivity


Provisioning


Security


Quality Of Service (
QoS
)


11073
-
20401
-
20130504.pptx


SLIDE
13

What’s next …


Next steps:

o
Align with IHE DPI Discussions @ Thursdays
11:00 “AFC” Pacific

o
Core content ready by 2013 September WGM

o
Draft ready by 2014 January WGM



Questions?

11073
-
20401
-
20130504.pptx


SLIDE
14

TISL


connectivity primitives


TISL_connectivity_init


TISL_connectivity_get_providers


TISL_connectivity_set_provider


TISL_connectivity_set_callback


TISL_connectivity_set_mode


TISL_connectivity_connect


TISL_connectivity_disconnect


TISL_connectivity_accept


TISL_connectivity_listen


11073
-
20401
-
20130504.pptx


SLIDE
15

TISL connectivity primitives continued


TISL_connectivity_send


TISL_connectivity_receive


TISL_connectivity_uninit



Preferred transport based on underlying
layer support.


11073
-
20401
-
20130504.pptx


SLIDE
16

TISL


Discovery of services and devices
primitives


TISL_discovery_init


TISL_discovery_get_providers


TISL_discovery_set_provider


TISL_discovery_set_service_callback


TISL_discovery_set_device_callback


TISL_discovery_start


TISL_discovery_cancel


TISL_discovery_uninit


Preferred provider SSDP

11073
-
20401
-
20130504.pptx


SLIDE
17

TISL provisioning primitives


TISL_provisioning_init


TISL_provisioning_get_providers


TISL_provisioning_set_provider


TISL_provisioning_add_item


TISL_provisioning_remove_item


TISL_provisioning_get_item


TISL_provisioning_uninit

Preferred provider based on type of transport


can be DHCP, directory or some other
mechanism



11073
-
20401
-
20130504.pptx


SLIDE
18

TISL security primitives


TISL_security_init


TISL_security_get_providers


TISL_security_set_provider


TISL_security_select_key


TISL_security_encrypt


TISL_security_decrypt


TISL_security_sign


TISL_security_verify_signature