Learn how to store and display medical device data for a Service opportunity.
In this guide, you’ll learn how to combine information from multiple Edge devices into a single, logical Thing.
You’ll then create a GUI to display this combined information (as well as retrieve new information on demand) to facilitate a “Medical Service Play”.
NOTE: The estimated time to complete ALL parts of this guide is 60 minutes
So far in this Learning Path, you've been able to connect both an embedded controller (simulated by a Raspberry Pi) and a PC to ThingWorx Foundation.
This is important, as medical devices can be complicated pieces of technology controlled by multiple "intelligent" subsystems. It is not always practical (or desirable) to have these subsystems communicate with each other, even if they all need to work together to function optimally.
Fortunately, Foundation has the capability to combine relevant data from multiple Edge devices into a single, logical Thing.
In this step of the Learning Path, you will do just that to facilitate a "Service Play".
The scenario is that your company manufactures and services Magnetic Resonance Imaging (MRI) devices.
Rather than simply servicing the MRI when there is an issue (and after a very expensive device has been damaged from something going wrong), your company maintains a continuing service contract with the hospital to monitor the MRI and perform preventative maintenance on it BEFORE anything goes wrong.
The value proposition to the hospital is the ability to keep their expensive investment in perfect operating order rather than suffering an unexpected failure. In turn, your company reaps the benefits of receiving a steady source of income from said service contract.
In order to achieve this level of preventative maintenance, your company needs to constantly monitor the MRI's various functions.
The MRI is composed of multiple working parts, but for this scenario, we'll limit our Minimum Viable Product (MVP) Service Application to the following:
In particular, it's important to note that this PC has access to patient medical data, which can be subject to Health Insurance Portability and Accountability Act (HIPAA) violations. Fortunately here again, it's possible to segregate this information into protected and non-protected sections to limit your company's liability. We'll only propogate non-protected, generalized information to Foundation, such as the total number of scans that have been run thus far. This can facilitate your company getting a connected device approved by a hospital worried about HIPAA-compliance.
To help you run through this guide, we'll also utilize a pair of "simulators" to mimic data coming from the EMS-es on the Pi and PC, rather than directly taking information from them. So if you had any issues with the previous steps getting the EMS running on these devices, you can still complete this guide without issue.
As mentioned, we'll be using a pair of simulators to mimic connections to both an embedded microcontroller and a PC, both of which are part of the MRI.
Perform the following steps to import the simulators.
Note how there are now several MDSD Entities. These represent Things connected to different parts of the MRI which are communicating to Foundation via the EMS Agent (as per the previous guides in this Learning Path).
Since there are multiple sub-systems which are all communicating directly to Foundation (but we really only want to check the status of the MRI as one logical entity), we need to know what exactly is being communicated back.
What is being communicated was likely determined by your company's Edge Developers when they implemented the EMS agent on said sub-systems.
Perform the following steps to investigate the simulators.
So the embedded microcontroller has sensors which are tracking the following:
Property Units Description
|Amount of coolant left to refrigerate the super-conducting magnets
|Strength of the magnetic field
|Temperature of the magnets
Next, let's look at the other simulator.
The PC is tracking information from the MRI controlling software, including the following:
|Number of Scans
|Aggregate count of all scans the MRI has performed since last reset
|SSD Space Open
|Amount of space left on the hard-drive
|Amount of RAM still available to the system
Both of these remote devices are communicating valuable information.
The embedded microcontroller is feeding us information about the hardware of the MRI itself. Refilling coolant as needed is likely one of the service contract stipulations and will be a regular service need. And a Field Strength drop or Magnet Temperature rise could indicate more significant issues which could damage the MRI if not promptly addressed.
The PC gives us information about the operation of the MRI. Hard-drive or RAM running low could indicate that the hardware specs of the PC need to be upgraded, while the Number of Scans can give us a rough estimate of how much refrigerant should have been used versus the currently available level. If only a handful of Scans have been run, but the amount of coolant has dropped by a significant amount, then there could be a leak somewhere which would need to be addressed.
The combination of the Embedded and PC data is enough for us to begin working on a constantly-monitoring application which will facilitate our Service Play.
Now that we're aware of what information is coming from the separate sub-systems of the MRI, we need to combine them into a single, logical Thing for the purposes of a Service Play.
To do so, we'll create a Thing which represents the MRI as a whole. Additional sub-systems can be added to to the collective information of this Thing as is necessary. But, as stated, this is simply an MVP, so we'll stick to the embedded and PC sub-systems at present.
A good way to aggregate multiple data points into a single item is via an Info Table Property.
However, any time you create an Info Table, you also need a Data Shape to format the "columns" of the spreadsheet-like Property.
For more information on the storage of "mass-data", please refer to the Methods for Data Storage guide.
Perform the following steps to create a Data Shape.
We now want to add Field Definitions to the Data Shape which map the information that we want to collate between the various sub-systems.
We'll start with the Embedded Microcontroller Properties.
Additional Definitions can be added at anytime as other sub-systems are included.
We'll now include the PC Properties.
It might also be benificial to include a Timestamp of when the values of both the embedded microcontroller and PC were added.
Click here to view Part 2 of this guide.