Rivian on FHIR®
Device On-boarding Example
Last updated
Device On-boarding Example
Last updated
This is an example of the flexibility of Healthcare Standard, FHIR@ (Fast Healthcare Interoperability Resources) and how it could be used to onboard a Medical Device for something like a Patient Home Monitoring solution where the device emits metrics back to the hospital as observations for external care.
Now, for fun and little profit, lets augment the scenario above and use FHIR to Deliver a Rivian to a Driver, and have it send back metrics to the Plant after the vehicle has been entitled to its new owner.
Though it may not be perfect, I think we can get this done with 5 FHIR Resource types.
Organization
Organization
Device
Device
DeviceMetric
DeviceMetric
Patient
Account
Observation
Observation
Now that we got things modeled, we are going to execute the workflow in two different parts. On boarding and Post Delivery Observation as a stateful API. The on boarding is done exactly once, the Post Delivery Observation posts continuously utilizing values from the on boarding process.
On boarding is quite simple, the Organization (Rivian) builds the Device (R1S), formulates the Metrics (telemetry) and associates it to its Account to take home.
Lets look at the payloads of the FHIR resources adapted to this Scenario.
Organization Rivian Headquarters, where the whip rolled out of the plant.
Device The whip itself. R1S to be exact.
DeviceMeasurements These are the metric "thingers" the device is capturing and capable of publishing, think of these as an envelop to the metric, declaring the data type, labels, and all that stuff around the unit of measure.
Account This is the owner of the vehicle, in this example myself.
Now, lets post these to the server and have a look at the result.
You can do this in a bundle, or individually as resources, but here we are going to do it as individual resources to drive home the order of events, and we'll use bundles for the next part of the workload.
Pay attention to the relationships built in the above payloads.... cause its awesome.
UNDER CONSTRUCTION HERE
So the above all happened and the Device (R1S) is now rolling all over the State of Michigan collecting and spewing forth Observations for remote monitoring. We're going to poll the Rivian API for the data, and ship it to a FHIR Server.
We have a trusty technique for scheduling the workload found in the Data Access section of the data adventure, Ill go over it again, but make it dismissable with one of those collapsble thingies, but show the script in its entirety that gets the job done.
Lets run it, if you are curious on we run python as kubernetes jobs, have a look at our foundational section, Data Access or the github repo associated with this post for clues.
Transaction Bundles Posting!
I wrote this up initially for participants of the MIT Hack in 2022 as a simple of example of how to do exactly the above using FHIR, and provided a postman collection of sorts to back it. It fits nicely for those wanting to understand how slick and powerful relationships between FHIR resources are, and t
Using , lets visualize our FHIR Resources and the relationships between them to model our payloads for the workload. The model the left is a somewhat accurate way to onboard a device for Remote Monitoring in a hospital, on the right, is how we would onboard the Rivian. represented in FSH (FHIR Shorthand) and visualized by gb2.
