Stream: implementers
Topic: Streaming realtime observations
Artem Polyakov (Feb 18 2021 at 13:04):
Hi All, could someone please suggest the right way of handling realtime observation data with Fhir. Use case is the following: we want to stream realtime ECG data to the server in order to display curve data to the user.
Lloyd McKenzie (Feb 18 2021 at 15:17):
Have you looked at the SampledData data type?
Lloyd McKenzie (Feb 18 2021 at 15:17):
(with Observation)
Artem Polyakov (Feb 18 2021 at 15:21):
yes, I did look at it. The question is how to handle a continuous stream of observations
Artem Polyakov (Feb 18 2021 at 15:21):
the one option is to send SampledData periodically
Artem Polyakov (Feb 18 2021 at 15:21):
but I don't really like this approach
Lloyd McKenzie (Feb 18 2021 at 15:42):
What would you propose instead?
Artem Polyakov (Feb 18 2021 at 15:43):
I would propose using websockets for realtime live data transfer
Lloyd McKenzie (Feb 18 2021 at 15:44):
Ok, but websockets containing what?
Lloyd McKenzie (Feb 18 2021 at 15:45):
If you're going to use FHIR, what is exchanged has to be stand-alone interpretable
Lloyd McKenzie (Feb 18 2021 at 15:46):
There's nothing to stop you from just sending a stream of values to a websocket, but that wouldn't be FHIR. FHIR would be what you turn that into for subsequent storage/exchange.
Artem Polyakov (Feb 18 2021 at 15:47):
I see, but in this case FHIR is not intended to be used for live data streaming
Lloyd McKenzie (Feb 18 2021 at 15:51):
FHIR can be, but if you're doing that, it'll be done by chunking. Either one Observation per value or one Observation with SampledData for some periodic chunk of data.
Lloyd McKenzie (Feb 18 2021 at 15:52):
I suppose you could also use a FHIR operation to say "Hey, I have a new value" and just keep calling the operation.
John Silva (Feb 18 2021 at 18:09):
And you'd need a FHIR repo that can "keep up" with the real-time storage and client access demands of this "high frequency" data. I've seen a similar use case with realtime data from physio monitors, e.g. vital signs every 30 seconds.
Gino Canessa (Feb 18 2021 at 18:47):
I've heard this raised as an issue a couple of times. From what I've seen:
- Use the data in a non-FHIR format, have a collection point that periodically transforms into SampledData and sends to a FHIR server.
- Pros: data is usable immediately, works with standard FHIR server (no custom code), resources are only stored once
- Cons: 'fast access' to data is not in FHIR, period delay in getting data into the FHIR server
- One OSS Example: (disclosure note - I work for MS, though not any of the IoMT teams)
- Send full FHIR resources (e.g., POST SampledData, followed by PUT or PATCH SampledData)
- Pros: fully FHIR
- Cons: many versions of resources, heavy device requirements (needs to not only generate FHIR, but track resource IDs over time, etc.).
- Define an operation that registers data with the FHIR server, and have it do the processing.
- Pros: data is always available in FHIR
- Cons: requires custom code on the server, updates to clients can be delayed, version management
Elliot Silver (Feb 18 2021 at 20:10):
I suppose you could also keep patching the same resource with the latest data.
Gino Canessa (Feb 18 2021 at 20:15):
@Elliot Silver yep, I consider that part of the second (create a resource then update it) but wasn't explicit about it. I've updated to include it, but wanted to add a note so your comment still makes sense =)
Artem Polyakov (Feb 19 2021 at 07:45):
guys, thanks very much for all the suggestions
Kevin Mayfield (Feb 19 2021 at 09:06):
How frequent is the real time data stream?
If it's relatively low I'm tending to favour a FHIR Message equivalent of 'unsolicited-observation' for a collection of Observations and DiagnosticReport or a POST /Observation or observation-event FHIR Message (the observation profile would be same/similar and use case dependent). [I've assumed it's a combination of all three]
Artem Polyakov (Feb 19 2021 at 09:07):
Kevin Mayfield said:
How frequent is the real time data stream?
If it's relatively low I'm tending to favour a FHIR Message equivalent of 'unsolicited-observation' for a collection of Observations and DiagnosticReport or a POST /Observation or observation-event FHIR Message (the observation profile would be same/similar and use case dependent). [I've assumed it's a combination of all three]
around 100 ms
Kevin Mayfield (Feb 19 2021 at 09:17):
Would be tempted to not use FHIR for the streaming. Does this may be blutooth interface at present? Wondering what the interaces are like, I think the amount of data they transmit is low. Such as datetime, deviceID and an array of observations normally of the form Obs Code and value.
Conversion to FHIR would probably occur but not at the streaming stage?
Artem Polyakov (Feb 19 2021 at 09:21):
Kevin, this is exactly one of the options that we're considering. But we have thee hard requirement from product owner to use FHIR only wherever it's feasible
Kevin Mayfield (Feb 19 2021 at 09:28):
I was thinking page 7 of this was more practical https://www.devdays.com/wp-content/uploads/2019/02/DD18-US-FHIR-and-Devices-Todd-Cooper-2018-06-19.pdf
(probably available on youtube)
So stage 1 - not FHIR
Stage 2 - maybe RESTful FHIR
Stage 3 - probably FHIR Message
The requirements change between stages.
Last updated: Apr 12 2022 at 19:14 UTC
