‘M2M HEALTH’ WORKING GROUP
Working Document
Convener:
TELECOMMUNICATION ENGINEERING CENTER
MINISTRY OF COMMUNICATIONS AND INFORMATION TECHNOLOGY
Date: 6th Aug 2014
Revision Number: 0.0.4
Table of Contents
1
Introduction .................................................................................................................................... 3
2
Documentation conventions........................................................................................................... 3
2.1
Terms and Abbreviations ........................................................................................................ 3
2.2
Device Classifications .............................................................................................................. 4
3
Use Cases ........................................................................................................................................ 5
4
Security ........................................................................................................................................... 6
4.1
Encryption of data ................................................................................................................ 6
4.2
Exchange of Security Keys between service and nodes ............................................... 6
5
Technology adopted Profiles .......................................................................................................... 6
6
APIs for Gateway Integration .......................................................................................................... 7
7
Applicable Standards for Health ..................................................................................................... 7
7.1
BIS Standards for Health .................................................................................................... 7
7.2
Electronic Health Record Standards For India August 2013 ......................................... 8
7.3
Continua Health Standards................................................................................................. 8
7.4
ISO Standards ...................................................................................................................... 9
7.5
HL7 Standards ...................................................................................................................... 9
8
References ...................................................................................................................................... 9
9
Feedbacks...................................................................................................................................... 10
10
Appendix of Use Cases Details ................................................................................................. 11
10.1
Personal health care device ............................................................................................. 11
10.2
Elderly care/ assisted living .............................................................................................. 12
10.3
Rural scenario ..................................................................................................................... 14
10.4
Ambulance/Mobile care ..................................................................................................... 16
10.5
Smart Wearable Devices .................................................................................................. 18
10.6
Asset Tracking and Device tracking inside hospital ...................................................... 20
10.7
Patient Identification........................................................................................................... 22
10.8
Remote Patent Monitoring ................................................................................................ 24
10.9
Clinical monitoring .............................................................................................................. 24
10.10
Radiology data transfers ............................................................................................... 24
10.11
Video conferencing ........................................................................................................ 24
10.12
Remote Drug Delivery ................................................................................................... 25
10.13
Remote Robotic surgery................................................................................................ 25
10.14
Tele-call center ............................................................................................................... 25
10.15
LIS (Laboratory information System) .......................................................................... 26
11
Revision History ........................................................................................................................ 27
1 Introduction
Kindly refer to Framework of Reference For Working groups of M2M domain.
Working group will identify a minimum set of common requirements of Healthcare
segment, focusing on vertical related market and application programming interfaces
(APIs) and protocols supporting applications and services, and draft technical reports
in these areas.
Working groups will make use of work already carried out by any other organizations
to the extent feasible to avoid duplication of work. Working groups will study
standards and specifications developed / being developed by international bodies
such as ETSI, IEEE and OneM2M etc. While preparing report / contribution, Indian
interest will be kept in mind. Documents available in TEC will be circulated to all
members.
Broad functions for working groups are envisaged as below:• Collect and document information from the global M2M community and from
vertical market entities on current activities and technical specifications including
requirements, use cases, service and business models, etc.
• Perform a gap analysis for vertical market M2M service layer needs, applications
and services and APIs & protocol.
• Identify a minimum common set of M2M service layer requirements and capabilities
focusing on concerned vertical applications and services.
• Study whether existing APIs and protocols satisfy the above requirements and
capabilities to support a common M2M service layer between M2M applications and
telecom networks.
• Draft technical reports describing and addressing the gaps and identifying future
standardization work.
• Working group will primarily focus on “applications and services”, “M2M use cases
and service models”, “M2M service layer requirements” and “M2M APIs and
protocols”. The working group on Gateway and Architecture, while working on
gateway requirements will take feedback from other working groups so as to address
their needs.
• Working group on a particular vertical will work in close collaboration with the stake
holders who are currently working on M2M or providing M2M services in India.
2 Documentation conventions
2.1 Terms and Abbreviations
BT
Bluetooth
BTLE
Bluetooth Low Energy
ECG
ECG Electrocardiography
EHR
Electronic Health Record
ITU
International Telecommunications Union
ISM
LAN
Industrial, Scientific and Medical Band of Spectrum
Like 2.4GHz, 865-868MHz
Local Area Network
M2M
Machine-to-Machine
NFC
Near Field Communication
QoS
Quality of Service
QOL
Quality of Life
RMD
Remote Monitoring Device
Sub-Gig
Sub Giga Hz Radio Communication
USB
Universal Serial Bus
WAN
Wide Area Network
2.2 Device Classifications
Country / Market
Risk / Example
US Market
EU Market
Risk Level
Example
Class I
Class I
Low Risk
Class II
Class II-a and
Class II-b
Moderate low
and high risk
Class III
Class III
High Risk
Non-Invasive
Electrodes
Electronic
thermometers,
stethoscopes and
blood pressure
monitors, ECG
Implantable defibrillator
and implantable
active device in general
Pandemic disease
diagnosis tool
3 Use Cases
Note: This section needs to be populated. It is suggested to keep 1 or 2 pages for each type of
the use-case. The information bulleted below to be filled and further information can be added
Usecase/
Device
Requirements
Type
Communicati
on Channel
Bandwidth
BT, ZigBee,
Low
Security Privacy
Data
QoS
Owner
Class I/
II/ III
Personal health
care device
II
H
H
User
Low
Sub-Gig,
(Preventive)
GPRS
Elderly care/
assisted living
II & III
Remote Patent
Monitoring
II & III
High
H
User,
Hospital
High
(Continuous care)
Rural scenario
II
Ambulance/
II & III
Mobile care
Clinical monitoring
I
Smart Wearable
Devices
I
Radiology data
transfers
II
Remote Robotic
surgery
III
Tele-call center
I
Asset Tracking and
Device tracking
inside hospital
I
Patient
Identification
I
Remote Drug
Delivery
III
Video conferencing
I
H
Dedicated
N/w
Legends:
H: High, L:Low, M:Medium
4 Security
4.1 Encryption of data
AES Encyption 128bit
4.2 Exchange of Security Keys between service and nodes
How will services exchange the Security keys
5 Technology adopted Profiles
Technology
Profiles adopted World-Wide
References
USB
Bluetooth(R)
Bluetooth SMART(R)
Blood Pressure
Heart Rate
Thermometer
Glucometer
Bluetooth SMART READY
(R)
NFC(ISO14443/ISO15693) Personal Health Device
Communication
PHDC 1.0
NFCForum-TS-PHDC-1.0
2013-02-27
6 APIs for Gateway Integration
Define the APIs requirement for integration with Gateway/Aggregator
7 Applicable Standards for Health
7.1 BIS Standards for Health
S.No
BIS Standards
Subject
MHD 17 HEALTH
INFORMATICS
SECTIONAL
COMMITTEE
SCOPE Standardization in the field of
information for health, and Health
Information and Communications
Technology (ICT) to achieve compatibility
and interoperability between Independent
systems. Also, to ensure compatibility of
data for comparative statistical purposes
(e.g. classifications) and to reduce
duplication of effort and redundancies.
To co-ordinate with the work of ISO/TC 215
Health informatics & its sub committee
IS/ISO 17115:2007 Health InformaticsVocabulary for terminological systems March
2011
IS/ISO 20301:2006 Health InformaticsHealth Cards-General characteristics March
2013
FINALISED DRAFTS UNDER PRINT
DOC.MHD 17(140)
Health Informatics-Digital Imaging and
Communication in / ISO 12052:2006
Medicine(DICOM)including workflow and
data management
DOC MHD 17
(0237)
Health Informatics-Electronic health record
communication— /ISO 13606-1:2008 Part 1:
Reference model
DOC MHD 17
(0238)
Health Informatics-Electronic health record
communication— /ISO 13606-2:2008 Part 2
Archetype interchange specification
DOC MHD 17
(0239)
Health Informatics-Electronic health record
communication— /ISO 13606-3:2009 Part 3:
Reference archetypes and term lists
DOC MHD 17
Health Informatics—Interoperability of
telehealth systems and networks- /ISO
Reference / Path
(0240)
16056-1:2004 Part 1: Introduction and
definitions
DOC MHD 17
(0241)
Health Informatics—Interoperability of
telehealth systems and networks- /ISO
16056-1:2004 Part 2 : Real-time systems
DOC MHD 17
(0242)
Health informatics-Requirements for an
electronic health record architecture
/ISO/TS 18308:2004
DOC MHD 17
(0243)
Health informatics-Electronic health recordDefinition, scope and context /ISO/TR
20514:2005
DOC MHD17 (313)
Health informatics- personal health devices
communication Part 10404 /ISO/IEEE
11073-10404 Device specialization-Pulse
oximeter
DRAFT APPROVED FOR WIDE CIRCULATION
DOC MHD 17
(0301)
Health informatics- good principles and
practices for a clinical data warehouse
ISO/TR 22221:2006
7.2 Electronic Health Record Standards For India August 2013
Approved by Ministry of Health & Family Welfare, Government of India
7.3 Continua Health Standards
www.continuaalliance.org
7.4 ISO Standards
ISO EN 13606 Electronic Health Communication (EHRCOM)
ISO Standards
Subject
ISO13485:2003
Medical devices - Quality
management systems Requirements for
regulatory purposes
Medical devices – Quality
management systems Guidance on the
application of ISO13485:2003
ISO/TR 14969
7.5 HL7 Standards
8 References
1. Frame of Reference (FOR) document from TEC
Reference / Path
9 Feedbacks
Kindly feel free to send your feedback to following
a. Sushil Kumar, DDG (S&D), TEC : sushil.k.123@gmail.com
b. Parmatma Rai, (Convener/Co-Rapporteur, TEC) : prai64@rediffmail.com
c. Ananda Sen Gupta (Rapporteur of WG, TrackMyBeat) :
ananda.sengupta@trackmybeat.com
d. Alok Mittal, Chairmain-WG, STMicroelectronics, alok.mittal@st.com
10 Appendix of Use Cases Details
Note: This section needs to be populated. It is suggested to keep 1 or 2 pages for each type of
the use-case. The information bulleted below to be filled and further information can be added
10.1 Personal health care device
a. Description and Block-Diagram
We can refer to the Continua Personal healthcare system
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.2 Elderly care/ assisted living
a. Description and Block-Diagram
Following Scenerios exist specific to Elderly care
i.
Fall condition: This is to detect if the user has fallen and unable to
get us due to injury. The message needs to be sent to nearby Family
members/Care Giver/ Hospital
ii.
Vital Signs monitoring : Need to monitor the health parameters and
alert the health-care services for alarms etc
iii.
Routine checkup : Routine checkup reminders and appointment
settings for monthly/timely basis
iv.
Scheduler for Medicines reminder: Regular medicines for Chronic
diseases to be taken and reminders to be given from the server to the
user.
The reminders can be managed locally also by an Smart-phone App
or other mechanism. However, usage of medicines needs to be
recorded
v.
Activity monitoring: General prescription for the movement of the
user, minimum steps taken and calories burnt per day monitoring
Kindly refer to Continue Block diagram for the devices like:
“Independent Living Activity”, “Activity Monitor” and “Medication
adherence”
b. Type of Device: Class 1/2/3
Type and 1 & 2
Only Post Surgical : Type 3
c. Communication channel used
BT/ BTLE/ ZigBee / Low Power RF in ISM Bands
This is mostly to allow user mobility in the home
USB: Wired connections only for specific parameter logging from specific
Instruments
2G/3G/4G/ Wifi/Broadband : for Server Connectivity through Gateway
d. Data bandwidth requirements
Low data rate for Personal care devices
e. Security requirements
Data shall be encrypted
f.
Privacy
Data access to be provided to user, Hospital,
Based on user agreement: It can be provided to Family members, Care giver,
Insurance Companies
g. Compliance to standard: Name
Kindly refer to Continue Block diagram for the devices like: “Independent Living
Activity”, “Activity Monitor” and “Medication adherence”
h. Deviations: from standard
i.
j.
k.
l.
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.3 Rural scenario
a. Description and Block-Diagram
TBD, but similar to Continua Health diagram)
In a rural health scenario, there are two typical scenarios:
i. A large number of users will be catered to at a health centre, and,
ii. An ASHA or ANW worker will visit individual user’s home to help monitor health
In either case, the monitoring will be done using multi-user personal health
devices.
The key challenge here is user identification. There must be a way of uniquely
identifying the user of the device, so that the data can be stored accurately
against the correct user in a centrally located server.
There are two options here:
i. Have the user identification to be in built in the device - where the device itself
exchanges data with a central server and has a process to identify the user. For
example, the device has a finger scanner which then connects to central server,
which responds with the matching user identification.
In this case, the device will directly connect to the network (hence will have a SIM
card) and will have an IP address.
ii. Have the user identification be done through a gateway device - tablet or
phone with SIM (with IP address). In this case, the tablet may have either a finger
scanner for greater accuracy, or for cheap practical use, have a database of
users, which the health personnel can select user identification from. The
minimum requirement in case of a database will be to display user’s name,
father’s name and/or address, so that the user can be chosen uniquely. In case,
Adhaar has been implemented, that could become an identifier through local
database. Technically, a personal computer can also be used as the gateway
device to communicate with the device and central server.
b. Type of Device: Class 1/2/3
The typical devices used will be type 1 and type 2. In special cases, there may be
type 3 devices at a health centre.
c. Communication channel used
Here the full connectivity scenario applies, as described in the Continua Health
connectivity diagram.
If the device communicates through a gateway device such as a tablet/phone/PC,
then the connectivity between the device and the gateway device will be
bluetooth/Zigbee/NFC/USB. The gateway device will connect using WAN
connectivity mechanisms to the central server on the cloud.
d. Data bandwidth requirements
The data bandwidth requirement for the basic health data transfer is low.
However, if a database has to be downloaded locally, a one time registration
process will be required for the gateway device which may have to hold a local
database with some minimum information describes previously to identify the
user uniquely. For that one time registration process, medium quantity of
bandwidth may be necessary, but it can also be done over a slower link since it is
a one time interaction.
e. Security requirements
The security requirements for the health scenario will be stringent as usual since
we are transmitting personal health data.
f.
Privacy
The privacy requirement will be high for personal health data. Processes will
need to be in place to protect against data misuse.
g. Compliance to standard: Name
TBD - suitable ISO and BIS standards
h. Deviations: from standard:
The user identification process will be unique for Indian rural scenario, which may
not apply in other situations (and in other countries).
i.
Challenges
As discussed, the key challenge here is user identification. Creating an accurate
user database is a substantial effort in a rural scenario. Hence, first, user data
collection is necessary, either from Census data or data from other local
authorities such as Panchayat and others. Once that is done, this data has to be
uploaded to a central location, which the local gateway or device has to access
and match with. In case a fingerprint database is to be maintained, or link has to
be made with Adhaar database, that will be yet another substantial effort. The
workaround that has been described is to have some basic user information
available, but even there the data has to be collected in advance. Adding new
users will also not necessarily be an easy process.
j.
Criticality of QoS
For type 1 and type 2 device usage scenario, the QoS requirement will be low as
the data collected is for longer term monitoring scenarios, and the volume of data
is also small.
k. Ownership of data
The ownership of data will of course lie with the user. However, since the rural
user is not a technologically advanced user, the Ministry of Health, Govt of India,
will have to involved in the processes and database management.
l.
Patient Safety Requirements
The devices will have to follow standard quality and safety standards as per BIS
or other applicable international standards if Indian standards do not exist.
10.4 Ambulance/Mobile care
a. Description and Block-Diagram
i.
There are following types of Ambulance services
 Advance transport ambulance: Contains special equipment
 Basic Life Support Ambulance
 Patient Transport Ambulance: Not much medical equipment are
there
ii.
Two-way communication is needed using UHF/VHF/ Cellular phones
This is needed to provide information to hospital about the Patient
condition and physical information.
Patient allergies needs to be recorded and informed to the hospital.
The medical equipment can be used which can be used for
measurement of the physical data and informed to the hospital
Video conference is also required for transferring medical information
of the patient
Online 12 Lead ECG which can be transmitted from moving
Ambulance. ECG with DICOM compatibility is useful.
iii.
iv.
v.
b. Type of Device: Class 1/2/3
Type 1/ 2: Vital parameters of the Patient
ECG: Type 3
c. Communication channel used
Since this is from Moving Vehicle, telecom network is mandatory to be used.
Hence 2G/3G/4G channels will be used from Ambulance to the Server/Hospital
Inside the Ambulance: Since the patient is stationary, wired connectivity can be
used Like USB for the vital parameters devices to the Aggregation manager.
It can be noted that inside the Automotive Vehicle, the electrical noise can be
high, hence the communication channel has to be robust
d. Data bandwidth requirements
Vital Signs: Low
ECG: High
Video Streaming: Very High
e. Security requirements
Data shall be encrypted and secure
f.
Privacy
Data access to be provided to Hospital directly. The usage of Ambulance would
mean that this is binding to the user
The data can be recorded and later provided to Family members, Care giver,
Insurance Companies
g. Compliance to standard: TBA
h. Deviations: from standard
TBA
i.
Challenges
It can be noted that inside the Automotive Vehicle, the electrical noise can be
high, hence the communication channel has to be robust
j.
Criticality of QoS
QoS has to be high. The Patient need immediate care, hence the Ambulance is
used.
k. Ownership of data
The ownership of data is to be with Hospital
l.
Patient Safety Requirements
TBA
10.5 Smart Wearable Devices
a. Description and Block-Diagram
The Smart wearable devices include the followings type. This list is not
exhaustive though
i.
Pedometer
ii.
Wearable ECG Patch
iii.
Pulse-Oximeter
iv.
Heart-Rate monitors
v.
Smart Glasses
The purpose of the smart-wearables is to monitor health of the user while being
worn by the user on the body. The recorded parameters can be stored on the
memory embedded in the design or transferred to the Aggregation manager
These devices need to be Battery operated since they need to be carried and
hence low-power consuming.
b. Type of Device: Class 1/2/3
Device Class will be 1 & 2
In some cases like ECG, it can be Class-3 Type
c. Communication channel used
Generally Low-Power connectivity channel to be used. These would include the
following technologies
i.
Bluetooth Low Energy
ii.
ZigBee
iii.
Low Power Radio
iv.
High bandwidth products like ECG may need Bluetooth
d. Data bandwidth requirements
Generally the devices shall consume low bandwidth only (< few Kbps).
e. Security requirements
f. Privacy
g. Compliance to standard:
The specific approved profiles of BTLE, BT, NFC can be used
h. Deviations: from standard
TBA
i.
Challenges
The data communication to be in small bursts of time to save the Battery
consumption.
Some companies have already launched their Smart-Watches and SmartWearables. The protocols used in these devices are to be mentioned.
( Proprietary./ Specific standards/ ).
j.
Criticality of QoS
Since these devices to be used in Personal Area Network, the QoS shall be good
from Device to the Aggregation Manager
k. Ownership of data
l.
Patient Safety Requirements
The radio transmission shall not cause any harm on the humans
10.6 Asset Tracking and Device tracking inside hospital
a. Description and Block-Diagram
Asset Tracking and Device Tracking is important aspect in the health sector
where all the health care instrument needs to be tracked in hospital.
RFID/NFC technology can play an important role in the asset tracking inside the
hospital. All the hospital equipment / instruments can have a NFC passive Tag
embedded with unique id of the instrument.
All the entrance/exit should have NFC transceiver which would record the
movement of the medical instrument/equipment and update in the database on
the hospital management system.
Whenever there is need to search the instrument/equipment the user can refer to
the Hospital Management system which will provide the last location of the asset
These tags can be mounted on the movable machines like X-Ray, UltraSound and similar equipments
b. Type of Device:
Class 1 type
c. Communication channel used
Near Field Communication (ISO14443 / ISO15693)
d. Data bandwidth requirements
Low data rate as NFC data rate 424 kb/s
e. Security requirements
No security requirements as we are just tracking the movement of the Hospital
equipment /instruments. The communication between the passive tag and the
NFC transceiver should be secure
f.
Privacy
No issue of privacy.
g. Compliance to standard:
ISO14443 / ISO 15693
h. Deviations: from standard : None
i.
Challenges:
All the existing instruments need to be tagged with passive NFC tag.
Active Transceiver gates need to be deployed as each entrance to track the
movement of the Medical instrument/equipment
The asset management system needs to be integrated in the Hospital
management system
j.
Criticality of QoS It is good to have but it will add value to the Hospital and
proper tracking can be done for each instrument
k. Ownership of data
The database will be owned by the hospital
l.
Patient Safety Requirements
No hazard or threat to the patient or Hospital
10.7 Patient Identification
a. Description and Block-Diagram
The Patient Identification is needed for correct logging of the data in the servers
and systems
These can be following types
i.
Biometric type : User uses the thumb impression as login in the system.
The
It can be linked to Aadhar system in India for validation and getting the user
details
This system is good for the Ambulance as well
ii.
RFID : Near Field communication tag unique to the user can be issued. It
will contain a unique ID for the user and when this Tag is put on the
authentication device, a unique number is used to get the Patient identity
etc. This can be good for Primary health care system
iii.
Iris Type: The eye scan can be used as unique identity. However, the
technology still needs to be deployed on mass-scale
iv.
Mobile Phone number: Users phone number can be used as unique ID.
Though the Mobile phone penetration in the population is high the
challenge is that all people do not have the mobile
v.
Smart-Cards : Smart cards can be used for the unique ID. These can be
ISO7816 compatible. The health-system must have the smart-card reader
input.
Each user must have a unique Health card which will help in identification.
vi.
TBA
b. Type of Device: Class 1/2/3
Class-1 type
c. Communication channel used
Biometric sensor: USB, Serial Interface (RS232, RS485)
RFID Tag: NFC
d. Data bandwidth requirements
Biometric/Finger print scanner needs authentication from the server and hence
need the Broadband/ WiFi/ Telecom network
From the sensor to the medical device, it will use wired connectivity and hence
Bandwidth requirements are low
e. Security requirements
Secure connection needed between the identifier and the Health System
f.
Privacy
All unique identifiers are non-transferable.
g. Compliance to standard: Name
TBA
h. Deviations: from standard
i.
Challenges
Using the identifier for the injured patient is a challenge.
Blood stains on the finger or eyes can disrupt the reading process
These are good for the Out-Patient healthcare requirements
j.
Criticality of QoS
It shall be treated as “Good to Have”
However, manual entry of the user can also be done.
k. Ownership of data
All patient data are owned by Patient and the Hospital
l.
Patient Safety Requirements
The unique identified not be pose a health hazard to the user
10.8 Remote Patent Monitoring
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
Description and Block-Diagram
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.9 Clinical monitoring
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
Description and Block-Diagram
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.10 Radiology data transfers
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
Description and Block-Diagram
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.11 Video conferencing
a. Description and Block-Diagram
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.12 Remote Drug Delivery
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
Description and Block-Diagram
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.13 Remote Robotic surgery
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
Description and Block-Diagram
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.14 Tele-call center
a.
b.
c.
d.
e.
Description and Block-Diagram
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
f.
g.
h.
i.
j.
k.
l.
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
10.15 LIS (Laboratory information System)
a. Description and Block-Diagram
Connecting various semi-automatic and automatic system to main system in a
laboratory/Hospital.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
Type of Device: Class 1/2/3
Communication channel used
Data bandwidth requirements
Security requirements
Privacy
Compliance to standard: Name
Deviations: from standard
Challenges
Criticality of QoS
Ownership of data
Patient Safety Requirements
11 Revision History
Date
Revision
History
6th Aug 2014
0.0.4
Use-case of Rural Health, Elderly care/
assisted living, Ambulance, Patient
Identification, Smart-Wearables Asset
tracking updated
5th Aug 2014
0.0.3
LIS (Laboratory Information system added)
as per feedbacks
14th July 2014
0.0.2
10th July 2014
0.0.1
Summary table of Use-case and features
added
Moved use cases to Appendix
New use-cases as discussed in conf call of
10th July added
First draft presented