Stream: Argo Write
Topic: Today's call
Josh Mandel (Jun 30 2021 at 18:03):
@Mike Lohmeier would love to hear the comment you were starting to make on today's call!
Mike Lohmeier (Jun 30 2021 at 18:53):
lol, thanks. I didn't realize we were over time already.
A lot of the discussion today was around the classic IoT problem of system responsiveness with device I/O. Generally speaking, most IoT systems disconnect the device I/O from the application API and make the interactions asynchronous for the following reasons:
- Devices are usually highly constrained and on unreliable hardware and networks. Rule of thumb is to get data off of small iron and onto big iron as fast and furious as possible. This is even true for mobile devices where carrier networks are unreliable and storage is compact flash.
- There are going to be issues in the field that are not instantaneously solvable. So, frameworks for resolving issues in the field server side for any combination of product, lot or firmware version are invaluable. Issues in mobile app code or firmware will be in the field until an update is installed where even the most optimistic path, mobile auto-update, will be days to get a large percent of the user base updated and have a long tail in months or years.
- A single signal from device data will typically generate n number of application API writes and the rules powering writes change frequently. For example, the blood pressure cuff could not only write the Observation but a DetectedIssue if it passes a threshold. Typically, these rules change very frequently and are dynamic so embedding them into a mobile app or firmware will make it very difficult to change. Also, writing all of these records using a single transaction keeps the consistency either all correct or all incorrect in regards to the single device interaction.
- Scalability of the transaction processing is limited by the data store. Ingress device data adds up quick and even at very low numbers it will have a direct impact on the behavior of an Application API when using a shared datastore. For implementations on shared relational datastores that use ATOMIC writes, the penalty will be seen through higher API response times and eventually timeouts. Implementations using NoSQL, are already accepting async writes through eventual consistency and will have the correctness problem until all nodes are written. The NoSQL asynchronous writes are easier hidden but still there.
These are some of the technical reasons that have lead to asynchronous IoT gateways that separate ingress data ACKing, workflows and robust device management frameworks. It looks like the indirect option is the start of an asynchronous IoT gateway that leverages the Task resource's workflow capabilities so it seems like it's on the right track.
I'll also echo a lot of the comments from the gentleman from Duke about impedance mismatches with device data and providers. We saw similar things at Propeller where the standard of care for asthma did not match reality once it was measured. For example, most providers believed that asthmatics are having asthma attacks in low numbers between yearly visits. So, for integration they typically wanted all remotely sensed asthma attacks on the patient's chart. What they quickly learned was that asthmatics have a lot of asthma attacks and would walk back wanting all the records and wanted summaries instead.
Josh Mandel (Jun 30 2021 at 19:17):
Thanks for these thoughts! I'll note that the technical use cases for async behavior (e.g., desire for queue-based processing models) may be quite different than clinical use cases for async behavior (e.g., desire for review). Capturing details in a "Task" might make sense when there's a person / clinical workflow involved, but for "purely techinical async handling" we might want something lower level (e.g., negotiation with Prefer: respond-async, and a set of conventions around this; was discussing this with Gino and Carl from my team at MS earlier today).
Mike Lohmeier (Jun 30 2021 at 20:46):
No problem, it's awesome to see this get some traction. Let me know if there's anything I can help with.
John Moehrke (Jul 06 2021 at 11:29):
The Devices workgroup should be involved. They have projects like Mike is explaining that are spanning multiple standards bodies.
Last updated: Apr 12 2022 at 19:14 UTC
