IOT Platform for Medical Devices using Salesforce

The last few years have seen a rapid growth in the field of Internet Of Things (IoT) for medical devices. We now have medical devices that can act as IoT sensors, measuring blood pressure, temperature, pulse, blood oxygen level, insulin, or other vital health information and transmitting it as IoT messages. We also have wearable devices, such as smartwatches, that can perform similar functions. In addition, we have actuators that can be connected to beds, lights, and other equipment and can act upon signals received wirelessly. Many of these devices can be controlled via apps on smartphones or from cloud-based control systems. These technologies have opened up a number of transformative opportunities in healthcare for device manufacturers, providers, payers, and pharmaceutical companies.

This post describes an IoT architecture for medical devices using Salesforce, Heroku, and Amazon Web Services (AWS).

Business scenario

Our business scenario, for the purposes of this post, is an organization that specializes in home-based health care for the elderly. Its customers are senior citizens (about 100,000) who have illnesses or chronic conditions and who prefer to be treated at home. The organization has many internal employees: call-center agents, field nurses, and doctors (about 1000) who can make house calls or provide services remotely using telemedicine. The external stakeholders of the organization are external care team members of the patient (such as therapists, dietitians, and fitness trainers), hospitals, pharmacies, and insurance companies.

This organization is looking to use IoT in its core business, to improve patient outcomes and provide better care overall. It plans to install devices and apps for patients in their homes. The data from these devices will be collected locally by hubs in patients’ homes and software apps installed on their mobile phones. The hubs and mobile apps will relay the data to the cloud for monitoring, analysis, and storage.

The other components of this architecture are:

1. Heroku to collect data for event monitoring and AI-based predictive analytics
2. Salesforce (the CRM platform connecting all stakeholders of the organization) to create cases and send messages
3. AWS to provide off-platform storage, data warehousing, and reporting

This diagram shows a high-level business overview of our scenario.

Components of the architecture

The components of this architecture include devices and hubs, Heroku, Salesforce, and AWS.

Devices and hubs

Each patient’s home is equipped with a number of IoT based sensors and actuators. A typical home could have multiple devices (including wearables) that use short-range protocols such as Wi-Fi, Zigbee, or Bluetooth to send data once every minute to the local hub located in the patient’s home. Apps running on the patient’s mobile phone can also act as receivers of IoT data.

The hub acts as an edge device that aggregates data locally and performs any local computations on the data. The hub would provide faster response for critical conditions than the IoT cloud since it avoids a round-trip delay to/from the cloud. For example, the hub could respond immediately to any alarms raised by the patient’s devices (such as, if the patient experiences a fall), by sending an emergency alert directly to a 24 x 7 patient care center.

While the hub acts as an edge computing device, the IoT cloud hosted in Salesforce Heroku acts as the IoT platform. This platform is used for more detailed monitoring and analytics. All data from the hubs is sent to the IoT platform on Heroku via the LAN, using protocols such as MQTT over HTTPS.

Heroku

Apache Kafka on Heroku
Apache Kafka on Heroku is an add-on that provides Kafka as a service with full integration into the Heroku platform.
Apache Kafka is a distributed commit log for fast, fault-tolerant communication between producers and consumers using message-based topics. Kafka provides the messaging backbone for building a new generation of distributed applications capable of handling billions of events and millions of transactions, and is designed to move large volumes of ephemeral data with a high degree of reliability and fault tolerance.

Producer applications
One or more applications (e.g. applications written in Node.js) act as producers that publish messages on various topics to Kafka. These applications act as clients implementing IoT protocols such as MQTT. They will provide REST APIs for devices to connect with them. A message originates from a device in a patient’s home and gets published in Kafka.

Consumer applications
Various consumer applications subscribe to the topics on Kafka. For example, an event monitoring application (written in Node.js) could consume messages from Kafka. It can detect abnormal events (such as blood pressure going above or below threshold limits) and record it in a persistent data store (e.g. PostgreSQL). A second predictive analytics application (written in Python) could also consume messages from Kafka and apply machine learning algorithms and training sets on the data to make predictions. A third application could serve as a bridge, consuming messages from Kafka and sending them to AWS Kinesis.

Heroku Postgres
Heroku Postgres is a highly performant, scalable, managed SQL database service provided by Heroku. It can serve as a cloud-based persistent data store for Heroku apps as well as connect with Salesforce via Heroku Connect. Our example uses Postgres to store Salesforce records relating to event monitoring and predictive analytics.

Salesforce

Salesforce is the CRM platform that brings together all the stakeholders of patient data in one place. Internal users of Salesforce include customer service agents, doctors, and nurses, who will act on the cases created in Salesforce. They will also be able to view reports and dashboards. External users include patients, hospitals, pharmacies, and insurance representatives, who will interact via the customer community portal.

The declarative capabilities of Salesforce can be used to create various types of follow up actions to events received from patient devices. Collaborative capabilities (e.g. Chatter) can be used by patients to communicate with their care team members. The community portal can serve both as a customer service portal and as a knowledge base for patients. A package such as Salesforce Health Cloud can be used to provide more specific healthcare-related features. Reports and dashboards can be built on various cases and other events. Mashups can be provided to bring in the analytics capabilities from apps hosted externally (such as Tableau from Redshift hosted in AWS). Various AppExchange packages (such as for sending SMS, collecting payments, and so on) from third-party providers can be accessed via the Salesforce AppExchange ecosystem.

Heroku Connect
Salesforce reads the data from Heroku Postgres via Heroku Connect. Via Heroku Connect, Salesforce CRM data from custom or standard objects (such as cases) can appear as records in PostgreSQL. Bidirectional sync can ensure that data can be created and modified in both places and synced seamlessly to both systems. For example, a case record can be created in Heroku Postgres that becomes a case in Salesforce and vice versa. Note: Although this sync does not happen in real time, it can be fairly quick if configured properly. This is why an IoT device needs to use a local hub for edge (real-time) communication and the Salesforce platform for near-real-time communication.

Once cases are created in Salesforce, the full power of the declarative CRM platform can be applied to the objects. For example, cases can be assigned various priorities depending on the types of events and routed to customer service agents with specific skills (omnichannel). An alarm can be assigned a high priority while a preventative checkup visit can be given a lower priority. Process Builder can be used to send in platform notifications, emails, or SMS alerts (using an SMS package from AppExchange).

Since we are dealing with sensitive patient information (protected health information or PHI), security of the data in transit and at rest is a key part of the design and is addressed below.

AWS

AWS will be used for long-term storage and data warehousing. Amazon S3 is a highly scalable and cost-effective object storage service that provides high reliability. Amazon Redshift is a fast and effective petabyte-scale data warehouse service. Connecting these services will be Kinesis (a scalable and durable data streaming service) and Kinesis Data Firehose (a service to capture, transform, and deliver streaming data to S3 and Redshift).

A consumer app on Heroku, running on Heroku Shield Private spaces for compliance requirements, will be used to stream the data into AWS Kinesis using its REST API. Kinesis streams are connected to Kinesis Data Firehose, which acts as a conduit to send data to various downstream systems. For long-term storage, the data is sent to S3. A subset of the records (filtered by Kinesis Data Firehose) is sent to the Redshift data warehouse. Long-term data is moved to an infrequently accessed tier on S3 and glacier storage after three and seven years respectively.

Tableau is used to analyze the data from the Redshift data warehouse. The Tableau server could run on an EC2 instance hosted in AWS. The Tableau UI can be rendered in Salesforce (as a Web tab or mashup) along with other dashboards and reports from Salesforce.

Large data volumes

Our organization has about 100,000 patients. Each patient is associated with approximately three devices. Each device sends an IoT message every minute. This generates about 500 million messages every day that are streamed to Apache Kafka on Heroku. If each message is roughly 100 bytes (consisting of basic information like device ID, token, and reading), this produces 50 MB data per day, or about 18 TB per year. This is the volume of data stored in S3 and Redshift.

For simplicity, we could assume that we are going to store all the messages received in long-term storage. However, if some messages are status checks (e.g. OK / Yes or No), that are not useful for data analysis, we can filter them out from the data stream before pushing to the data warehouse.

Assuming that about .01% of the IoT messages result in alarms, we could have 50,000 cases a day in Salesforce or about 20M cases a year. After a case is closed, it could be moved out of Salesforce and archived. One archival strategy could be to move the closed cases to another database in Heroku, one that is not being synced with Salesforce through Heroku Connect.

Security

Security is a very important piece of this design. This solution deals with PHI and has to be HIPAA compliant. For this purpose, we should ensure that the data is secured in transit and at rest using various means available. It uses Heroku Shield, a set of Heroku platform services that offer additional security features needed for building high-compliance applications.

To secure the data in transit, all device hubs will be encrypted with X509 certificates (public key) and a token that is specific to each hub. The producer apps on the Heroku platform will have the private key of the certificate. All communication will be secured using TLS. All APIs will be secured using an API key / secret.

To secure the data at rest, we can use Salesforce Shield on the Salesforce side and various encryption schemes to encrypt data stored in PostgreSQL (e.g. PGCrypto), S3, and Redshift (e.g. SSE-S3, AES-256).

Scalability and availability

To ensure scalability, the producer apps could be hosted on multiple dynos on Heroku. Apache Kafka on Heroku has built-in scalability. The managed services in AWS are hosted in multiple availability zones (AZs) and also have built-in scalability. Salesforce availability is provided through site switching.

Conclusion

The increasing proliferation of IoT-enabled medical devices has made it possible to provide remote monitoring and diagnosis of patients’ health.

This post provides a high-level overview of an IoT platform for medical devices using Salesforce, Heroku, and AWS.

Salesforce provides a proven CRM platform that can bring together various stakeholders involved in providing care for patients and and can be used to build apps rapidly using a declarative framework. Salesforce Heroku provides a scalable platform to create cloud-based server applications for monitoring and predictive analytics. And AWS provides excellent off-platform capabilities for storing large data volumes and performing trend analysis on historical data.

• How is IoT revolutionizing the medical device service
• Analyzing Salesforce data with Heroku, Kafka and Connect
• Heroku Connect on Trailhead
• Event driven architecture with Apache Kafka on Heroku

About the Author

Varad G. Varadarajan is a Senior Manager and Program Architect at Salesforce. He is an active member of Salesforce’s “Scale and Availability Ambassador Program” ~ Architect Think Tank within Salesforce’s Success Organization. He has worked on multiple Salesforce implementations and cloud platforms such as AWS, Cloud Foundry, and Heroku. He is a Salesforce Certified Applications and Systems Architect (16X), certified Heroku Architect, and a certified AWS Solutions Architect. He has over 25 years of experience in IT in roles such as Business / Enterprise Architect, Chief Architect, and CTO.