Strategic Technology Architectural Roadmap

1. Rakesh Radhakrishnan
A STAR (Standards (driven) Technology Architecture Roadmap) for DHD (Digital Health Development)

2. Agenda
1.Medical Devices (FDA classifications)
2.Connecting Devices (BAN)
3.BAN to Mobile Devices
4.Mobile Medical Applications
5.Mobile Devices to Access Networks (3G, 4G, etc.)
6.Medical Cloud Services
7.Security Standards
2

3. Agenda
1.Medical Devices (FDA classifications)
2.Connecting Devices (BAN)
3.BAN to Mobile Devices
4.Mobile Medical Applications
5.Mobile Devices to Access Networks (3G, 4G, etc.)
6.Medical Cloud Services
7.Security Standards
3

4. Medical Devices
•Most medical devices can be classified by finding the matching description of the device in Title 21 of the Code of Federal Regulations (CFR), Parts 862-892.
•FDA has classified and described over 1,700 distinct types of devices and organized them in the CFR into 16 medical specialty "panels" such as Cardiovascular devices or Ear, Nose, and Throat devices.
•These panels are found in Parts 862 through 892 in the CFR. For each of the devices classified by the FDA the CFR gives a general description including the intended use, the class to which the device belongs (i.e., Class I, II, or III), and information about marketing requirements.
•A FDA regulated medical device should meet the definition in a classification regulation contained in 21 CFR 862-892.
•Class 1, 2 and 3
–Class I devices are deemed to be low risk and are therefore subject to the least regulatory controls. For example, dental floss is classified as Class I device.
–Class II devices are higher risk devices than Class I and require greater regulatory controls to provide reasonable assurance of the device’s safety and effectiveness. For example, condoms are classified as Class II devices.
–Class III devices are generally the highest risk devices and are therefore subject to the highest level of regulatory control. Class III devices must typically be approved by FDA before they are marketed. For example, replacement heart valves are classified as Class III devices.
4

5. Medical Devices
5

6. Medical Devices
•Medical Diagnostic Devices (pneumothorax detector – debris)
•Medical (drug) Delivery Devices (auto injectors)
•Some are embedded within the human body (pace makers
(aka Implantable Cardiovascular Defibrillator – ICD)
•Some are augmenting devices (implanted hearing aids)
•Majority are Sensors, RFID enabled
and transfer data over Bluetooth or
other BAN (body area network) spectrum
6

7. Medical Devices Sensor & Stimulators
• pH value sensor
• Glucose sensor
• Electro Encephalography (EEG )
• Electromyography (EMG) (muscular)
• Brain liquid pressure sensor
• Fertility Monitor
• Endoscope (gastrointestinal)
• Temperature Modulation Therapy (TMT)
• Temperature monitor
• Blood pressure sensor
• Mechanical motion sensors
• Respiratory monitor
• Saturation of Peripheral Oxygen (SpO2) - pulse oximeter
• Heart rate monitor
• Electro Cardiogram (ECG)
7
• Deep brain stimulator - Parkinson’s disease • Cortical stimulator • Epilepsy Stimulator • Visual neuro stimulator • Audio neuro stimulator • Muscular stimulator • Insulin pump • Internal cooling -Temperature Modulation Therapy • Wireless capsule for drug delivery

8. Agenda
1.Medical Devices (FDA classifications)
2.Connecting Devices (BAN)
3.BAN to Mobile Devices
4.Mobile Medical Applications
5.Mobile Devices to Access Networks (3G, 4G, etc.)
6.Medical Cloud Services
7.Security Standards
8

9. Connected Device (BAN)
9
•A body area network (BAN), also referred to as a wireless body area network (WBAN) or a body sensor network (BSN), is a wireless network of wearable computing devices.
•BAN devices may be embedded inside the body, implants, may be surface-mounted on the body in a fixed position Wearable technology or may be accompanied devices which humans can carry in different positions, in clothes pockets, by hand or in various bags.
•Whilst, there is a trend towards the miniaturization of devices, in particular, networks consisting of several miniaturized body sensor units (BSUs) together with a single body central unit (BCU), larger decimeter sized (tab and pad) sized (mobile) smart devices, accompanied devices, still play an important role in terms of acting as a data hub, data gateway and providing a user interface to view and manage BAN applications
•The FCC has approved the allocation of 40 MHz of spectrum bandwidth for medical BAN (as opposed to using Bluetooth spectrum) – IEEE 802.15.4
•BAN applications can run on a Mobile Device (like an Android or an i-phone)

10. Connected Device (BAN)
10

11. BAN Depth and Specialties
11
•Electromagnetic-Body Area NanoNETworks (E-BANNET) e.g., Nanobots traversing as Nanonets to study Blood Flow
•Unconventional Intra-body Communication (UNIC) website e.g., Alternatives to RF - acoustic/ultrasonic, galvanic or magnetic communications between nanobots
•Technologies and Applications for Telerehabilitation (TAT) e.g., remote physical therapy and training
•Privacy, Security and Trust in Body Area Networks (PSTBAN) e.g., light weight approaches to privacy and security in BAN – ssl vs Kssl
•Millimeter-wave Body Area Networks (MilliBAN) e.g. BAN WAN connectivity (4G and 5G)
•Cloud-assisted Cyber-Physical Systems (CCPS) e.g. Cloud assisted BAN, M2M, NFC, RFID. IOT, Sensor Actuator Networks, etc. (aligning with physical security as well)
•Coding for Emerging Wireless Networks (CEWN) e.g., programmable code, micro code, zero footprint code, etc.
•Human Body Communications (HBC) eg., using human body as a communication route to send data
•Antennas and Propagation in Body Area Networks (APBAN) e.g., miniature smart antennas for BAN

12. BAN Challenges
12
Interoperability: WBAN systems would have to ensure seamless data transfer across standards such as Bluetooth, ZigBee etc. to promote information exchange, plug and play device interaction. Further, the systems would have to be scalable, ensure efficient migration across networks and offer uninterrupted connectivity. System devices: The sensors used in WBAN would have to be low on complexity, small in form factor, light in weight, power efficient, easy to use and reconfigurable. Further, the storage devices need to facilitate remote storage and viewing of patient data as well as access to external processing and analysis tools via the Cloud. System and device-level security: Considerable effort would be required to make BAN transmission secure and accurate. It would have to be made sure that the patient ‘’secure‘’ data is only derived from each patient's dedicated BAN system & is not mixed up with other patient's data. Further, the data generated from WBAN should have secure and limited access. Invasion of privacy: People might consider the WBAN technology as a potential threat to freedom, if the applications go beyond "secure" medical usage. Social acceptance would be key to this technology finding a wider application. Sensor validation: Pervasive sensing devices are subject to inherent communication and hardware constraints including unreliable wired/wireless network links, interference and limited power reserves. This may result in erroneous datasets being transmitted back to the end user. It is of the utmost importance especially within a healthcare domain that all sensor readings are validated. Data consistency: Data residing on multiple mobile devices and wireless patient notes need to be collected and analyzed in a seamless fashion. Within body area networks, vital patient datasets may be fragmented over a number of nodes and across a number of networked PCs or Laptops. If a medical practitioner′s mobile device does not contain all known information then the quality of patient care may degrade. Interference: The wireless link used for body sensors should reduce the interference and increase the coexistence of sensor node devices with other network devices available in the environment. This is especially important for large scale implementation of WBAN systems. Data Management: As BANs generate large volumes of data, the need to manage and maintain these datasets is of utmost importance.

13. BAN The 4 C’s
13
Cost: Today's consumers expect low cost health monitoring solutions which provide high functionality. WBAN implementations will need to be cost optimized to be appealing alternatives to health conscious consumers. Constant monitoring: Users may require different levels of monitoring, for example those at risk of cardiac ischemia may want their WBANs to function constantly, while others at risk of falls may only need WBANs to monitor them while they are walking or moving. The level of monitoring influences the amount of energy required and the life cycle of the BAN before the energy source is depleted. Constrained deployment: The WBAN needs to be wearable, lightweight and non intrusive. It should not alter or encumber the user's daily activities. The technology should ultimately be transparent to the user i.e., it should perform its monitoring tasks without the user realizing it. Consistent performance: The performance of the WBAN should be consistent. Sensor measurements should be accurate and calibrated, even when the WBAN is switched off and switched on again. The wireless links should be robust and work under various user environments.

14. Agenda
1.Medical Devices (FDA classifications)
2.Connecting Devices (BAN)
3.BAN to Mobile Devices
4.Mobile Medical Applications
5.Mobile Devices to Access Networks (3G, 4G, etc.)
6.Medical Cloud Services
7.Security Standards
14

15. BAN to Mobile as a Hub/Gateway
15

16. BAN in a Hospital (multi-patient)
16

17. BAN to Mobile Gateway
17
•Mobile Devices are Ideal for Mobile (on the move) Patients
•Mobile Devices can support Bluetooth, Zigbee and BAN communication protocols on one end and 3G, 4G and 5G as well on the other end (acting as a getaway)
•Mobile Devices can be configured to bootstrap to specific Health Care Clouds (HIE’s, NHIN, and others).
•Mobile Devices can request User/Patient authentication and privacy enhancing tool (if needed) before and after Data and Events are sent (message level authentication)
•Mobile Device can act as conduit to enable programmability of sensor devices
•This approach can also extend the value of Mobile Medical Apps (Use Interface Centric)
•Mobile offers the UI for all sensor and stimulator apps in the BAN

18. Agenda
1.Medical Devices (FDA classifications)
2.Connecting Devices (BAN)
3.BAN to Mobile Devices
4.Mobile Medical Applications
5.Mobile Devices to Access Networks (3G, 4G, etc.)
6.Medical Cloud Services
7.Security Standards
18

19. Mobile Medical Apps
19
•Mobile Devices are Ideal for Mobile (on the move) Patients
•Mobile Devices can support Bluetooth, Zigbee and BAN communication protocols on one end and 3G, 4G and 5G as well on the other end (acting as a getaway)
•Mobile Devices can be configured to bootstrap to specific Health Care Clouds (HIE’s, NHIN, and others).
•Mobile Devices can request User/Patient authentication (if needed) before and after Data and Events are sent (message level authentication)
•Mobile Device can act as conduit to enable programmability of sensor devices
•This approach can also extend the value of Mobile Medical Apps (Use Interface Centric)
•Mobile offers the UI for all sensor and stimulator apps in the BAN

20. Mobile Medical Apps
•Mobile medical apps are medical devices that are mobile apps, meet the definition of a medical device and are an accessory to a regulated medical device or transform a mobile platform into a regulated medical device.
•Mobile applications (apps) can help people manage their own health and wellness, promote healthy living, & gain access to useful information when and where they need it.
•These tools are being adopted almost as quickly as they can be developed. According to industry estimates, 500 million smartphone users worldwide will be using a health care application by 2015, and by 2018, 50 percent of the more than 3.4 billion smartphone and tablet users will have downloaded mobile health applications (http://www.research2guidance.com/500m-people-will -be-using-healthcare-mobile- applications-in-2015/). These users include health care professionals, consumers, and patients.
•The FDA encourages the development of mobile medical apps that improve health care and provide consumers and health care professionals with valuable health information. The FDA also has a public health responsibility to oversee the safety and effectiveness of medical devices – including mobile medical apps.
•The FDA issued the Mobile Medical Applications Guidance for Industry and Food and Drug Administration Staff on September 25, 2013
20

21. FDA regulated Mobile Medical Apps
The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that:
•are intended to be used as an accessory to a regulated medical device, or
•transform a mobile platform into a regulated medical device.
•Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review.
•Please visit the mobile medical apps example page for a list of examples of mobile medical apps that have been cleared or approved by the FDA. Visit the Examples of MMAs the FDA regulates webpage for a more detailed list of examples of mobile apps that would require FDA review.
•For a list of what is considered a mobile medical application, manufacturers and developers of mobile applications can search FDA’s database of existing classification by type of mobile medical application (for example diagnostic). Approved/cleared mobile medical applications will also be listed in FDA’s 510(k) and PMA databases and on the FDA’s Registration & Listing Database.
•FDA’s mobile medical apps policy does not require mobile medical app developers to seek Agency re-evaluation for minor, iterative product changes.
21

22. FDA regulated Mobile Medical Apps
•Mobile apps that use a sensor or lead that is connected to a mobile platform to measure and display the electrical signal produced by the heart (electrocardiograph or ECG). Mobile apps that use a sensor or electrode attached to the mobile platform or tools within the mobile platform itself (e.g., microphone and speaker) to electronically amplify and “project sounds associated with the heart, arteries and veins and other internal organs” (i.e., an electronic stethoscope).
•Mobile apps that use a sensor or electrode attached to the mobile platform or tools within the mobile platform itself (e.g., accelerometer) to measure physiological parameters during cardiopulmonary resuscitation (CPR) and give feedback about the quality of CPR being delivered.
•Mobile apps that use a sensor attached to the mobile platform or tools within the mobile platform itself to record, view, or analyze eye movements for use in the diagnosis of balance disorders (i.e., nystagmograph).
•Mobile apps that use tools within the mobile platform (e.g., speaker) to produce controlled levels of test tones and signals intended for use in conducting diagnostic hearing evaluations and assisting in the diagnosis of possible otologic disorders (i.e., an audiometer).
•Mobile apps that use a sensor attached to the mobile platform or tools within the mobile platform itself (e.g., accelerometer) to measure the degree of tremor caused by certain diseases (i.e., a tremor transducer).
22

23. FDA regulated Mobile Medical Apps
•Mobile apps that use a sensor attached to the mobile platform or tools within the mobile platform itself (e.g., accelerometer, microphone) to measure physiological parameters (e.g., limb movement, electrical activity of the brain (EEG)) during sleep and are intended for use in diagnosis of specific diseases or conditions such as sleep apnea.
•Mobile apps that use an attachment to the mobile platform to measure blood oxygen saturation for diagnosis of specific disease or condition.
•Mobile apps that present donor history questions to a potential blood donor and record and/or transmit the responses to those questions for a blood collection facility to use in determining blood donor eligibility prior to collection of blood or blood components.
•Mobile apps that use an attachment to the mobile platform to measure blood glucose levels.
•Mobile apps that use that use an attachment to the mobile platform (e.g., light source, laser) to treat acne, reduce wrinkles, or remove hair.
•Mobile apps that use a microphone or speaker within a mobile platform to serve as a audiometer to allow healthcare providers to determine hearing loss at different frequencies.
•Mobile apps that analyze an image of a skin lesion using mathematical algorithms, such as fractal analysis, and provide the user with an assessment of the risk of the lesion.
23

24. MMA Standards
1.Password Free (recognition based authentication)
2.Cookie free
3.State Less
4.Zero Footprint
Standards for MMA https://www.leadtools.com/sdk/medical/html5.htm
1.DICOM
2.PACS
3.HTML5
4.RESTful
5.SIM (3GPP)
24

25. Agenda
1.Medical Devices (FDA classifications)
2.Connecting Devices (BAN)
3.BAN to Mobile Devices
4.Mobile Medical Applications
5.Mobile Devices to Access Networks (3G, 4G, etc.)
6.Medical Cloud Services
7.Security Standards
25

26. Mobile to 4G and 5 G networks
•As of 2014 – 4GLTE networks are prevalent in the US
•Early trials of 5G networks are expected in 2015-2016 timeframe with widespread proliferation by 2022
•SIM (subscriber identity module) enabled mobile devices maintain a high integrity bootstrap process with 4G networks (GBA and GAA – 3GPP standards)
•4GLTE is a global IEEE standard as well
•Wide bandwidth 3GB per sec (downloads) – implies HIGH throughput transmissions of medical data and medical images (multi-media)

27. Agenda
1.Medical Devices (FDA classifications)
2.Connecting Devices (BAN)
3.BAN to Mobile Devices
4.Mobile Medical Applications
5.Mobile Devices to Access Networks (3G, 4G, etc.)
6.Medical Cloud Services
7.Security Standards
27

28. Medical Cloud Services
•Cloud Foundry (PAAS)
•Openstack (IAAS deployment model) to AWS (public IAAS)
•Spring Framework for Security Standards (JAAS, JCE, PKI, SAML, XACML, XKMS, etc.)
•HIE (health information exchanges in the cloud) with HL7/XML standard interfaces
•Other REST API based Cloud Services (health care)

29. Medical Cloud Services (Data)
•Hadoop, NoSQL, MapRed, Tuples, Tensor and DDS
•Data Defined Storage in Big Data – leveraged by Storage as a Service platforms
•MDM (data classification and data models) infused with Big Data Technologies for SIEM (Risk based AuthN, Risk based AuthZ and Risk based Logs)
•API standards for HealthCare (SMART Service API on top of HC data/record) http://docs- v06.smartplatforms.org/
•Privacy and Security by DESIGN (CIPT) – FPE and FHE (CSA standards)

30. Agenda
1.Medical Devices (FDA classifications)
2.Connecting Devices (BAN)
3.BAN to Mobile Devices
4.Mobile Medical Applications
5.Mobile Devices to Access Networks (3G, 4G, etc.)
6.Medical Cloud Services
7.Security Standards
30

31. Security Standards
•NIST HIE standards http://csrc.nist.gov/publications/nistir/ir7497/nistir-7497.pdf

32. XACML and Privacy Principles
32
Proactive not Reactive; Preventative not Remedial
•XACML defines an architecture enacted at runtime
Privacy as the Default Setting
•XACML policies enable exact privilege settings
Privacy Embedded into Design
•IT projects can focus on authorization requirements on the one hand and business requirements on the other
•Clear separation of concerns

33. 33
Full Functionality — Positive- Sum, not Zero-Sum
•XACML is a business enabler
•It allows for data to be securely shared
•XACML helps deliver new services
End-to-End Security — Full Lifecycle Protection
•XACML policies evolve with the data they protect
•XACML policies can adapt to regulatory change
Visibility and Transparency — Keep it Open
•XACML policies are centrally managed and can be easily audited
•XACML policies mirror business requirements closely
Respect for User Privacy — Keep it User-Centric
•XACML policies focus on the entire picture: from who is accessing the data to the relationships to the purpose of use…
XACML and Privacy Principles

34. 34
•A common police framework for all Digital CODE (embedded in mobile to the Cloud)
•Automation from NPL to MPL to DPL (NIST recommended for HIE and for policy automation from natural policy language to meta policy language to digital policies)
•Data Defined Storage in Big Data – leveraged by Storage as a Service platforms -> translatable to XACML policies
•XACML supports ACL, RBAC, ABAC and Risk based AC
•XACML support API level Access Controls
•Privacy and Security by DESIGN (CIPT) – FPE and FHE (CSA standards) enabled by XACML
•DLP, Data Tokenization, DRM and DB firewalls support XACML
•HIE Privacy WG recommends XACML extensively
XACML Architecture and Reference Model gives the following for DHD