Remote Patient Monitoring Architecture

Remote Patient Monitoring is one of the hottest markets in healthcare.  The problem with Frontier Technologies is that usually, by the time policies and practices are defined, the technology has already been deployed.  This is certainly the case here.  There is still time to define best practices and stop the healthcare breach nightmare that is impending.  Secure policies involve numerous components, eg., a trained workforce, and an adherence to privacy and security practices.

The components of an E2E architecture for Remote Patient Monitoring (RPM) have been identified here.

In reviewing the applicable governing standards, industry publications and agency protocols that can be applied to “remote patient monitoring”, RPM, it’s important to understand that

medical devices are a subset of both MHealth (mobile health) and EHealth (electronic health or health informatics), where MHealth represents the subset practice of medicine and public

health supported by medical devices, and EHealth represents the larger discipline of healthcare practices supported by electronic processes and communications.  Understanding

the hierarchy of these practices allows for a greater ability to identify applicable standards and opportunities for collaboration.  Additionally, the scope of RPM, as a subset of telehealth,

is now expanded to the greater discipline of Cybermedicine, defined as the use of the Internet to deliver medical services, such as medical consultations and drug prescriptions.  (More extensive descriptions of MHealh, EHealth & Cybermedicine can be found using Wikipedia)

E2E Architecture components for Remote Patient Monitoring

Device: devices may be self-contained or integrated via software applications on patient devices:

1. Original equipment from manufacturer (OEM)/healthcare delivery organization (HDO)
   1. Hardware
      1. Wearables/Stand-alone Devices
   2. Patient BYOD
      1. Software (Telehealth Application)
         1. Operating system applications
            1. IOS XX.Xv
            2. Android X.Xv
            3. Windows based application
            4. Apple OS application
            5. Linux

 Environments: environments include all components of the telehealth platform

1. HDO environment
2. Patient’s environment

Methods of Connectivity: methods identify how the device could monitor and/or transmit data, apply updates and conduct triage/repair et al

1. Bluetooth
2. Cellular network
3. Secured Wi-fi
4. Ethernet
5. Virtual Private Network (VPN)

Carrier:data is passed along a series of nodes from end to end

1. Internet Service Providers
2. Mobile Networks
3. Non-ISM Radio Communications
   1. Medical Radio Communications (MedRadio)
   2. Medical Micropower Networks (MMNs)
   3. Medical Body Area Netwoks (MBANs)
   4. Wireless Medical Telemetry Service (WMTS)

Governance, Risk & Compliance: GRC identifies regulatory agencies (via standard, rule of law and collaborative necessity)

1. Federal Communications Commission (FCC)
2. Health and Human Services (HHS)
   1. HITECH Act
      1. HIPAA
   2. Centers for Medicare & Medicaid Services (CMS)
3. NIST
   1. National Vulnerability Database
   2. Draft NISTIR 8196 Security Analysis of First Responder Mobile and Wearable Devices
4. Federal Trade Commission (FTC)
5. Food and Drug Administration (FDA)
   1. MITRE Corporation’s Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook.
6. Institute of Electrical and Electronics Engineers (IEEE)
   1. 11073 medical device standards
   2. 802 series standards
7. Bluetooth Special Interest Group (SIG)
8. International Organization for Standardization (ISO) IEC 80001/60601
9. State and Federal privacy laws, including breach reporting protocols
10. California Telehealth Advancement Act
11. Department of Homeland Security (DHS)
12. Partner & Complimentary Organizations
    1. HIMSS
    2. Private partnership Clearwater and CyberMDX: Blueprint for Medical Device Security
    3. Centers for Connected Health Policy
    4. National Consortium of Telehealth Resource Centers
    5. The Center for Telehealth and E-Health law
    6. Advancing Safety in Health Technology
    7. FirstNet

End to End service disruptions/restoration et al

1. Cyberattacks
   1. Denial of service
   2. Man-in-the-middle
   3. Ransomware
2. Device Tampering
3. Connectivity failures
4. Device failures
5. User errors
6. Emergency Protocols

Defining a Best Practice Risk Management approach:

AVOID

Based on current RPM deployment vulnerabilities, i.e. FITBIT, risk avoidance could determine that RPM technology should not be deployed.

ACCEPT

Since RPM has already been deployed to market, a risk analysis should be performed to identify best practices for self-contained vs patient BYOD to reduce risk to minimal acceptable levels.

TRANSFER

End users represent ongoing and uncontrollable exposure to extreme vulnerabilities.   RPM practices can identify how risk can be transferred from the end user (patient) to the HDO.  Utilizing Digital Twin processes in both self-contained devices and in software API’s would allow data validation and real time functionality to ensure best possible outcomes for the patient(s) and provider(s).

.