Hi. I am a newbie to FHIR, but I am trying to build a very complex solution, so I could use some advice.
We have an application that is very good at collecting data from point-of-care devices in hospitals (e.g. patient monitors). These devices provide patient observation data like heart rate, EKG, etc. I would like to add FHIR capability to our application such that it can transmit these observations onward to external HIS or EMR systems. Keep in mind that there is potentially a lot of data to transmit. Just a few of these waveforms could easily generate thousands of datapoints per second.
I think that if this were a HL7 v2 solution, it would be easy enough. I would create an ORU-R01 message and send it via MLLP. But with FHIR I am very confused how to proceed:
Should our application be a “FHIR Client” which sends data to the recipient (which would then be a FHIR Server)?
What paradigm should we use to transmit the data? Due to the “event based” nature of these vital signs, I am wondering if messaging would be better than REST.
Or… I think abother solution would to add a FHIR Facade to my application and allow clients to query it for observations. The downside to this is that we would only provide the most recent values… and how would clients know when a new value is available?
Unless you’re planning to persist large volumes of data for extended periods of time (and manage permissions around who’s allowed to see what when), acting as a client and pushing the data to a server (that does have the persistence and permissions capabilities) is probably best.
Messaging adds a fair bit of overhead, so pure REST is probably simplest. If you’re transmitting waveform data, look at the SampledData data type. It allows you to transmit all of the data-points from a single period in one Observation instance. (How long a period makes sense depends on your sampling rate.)
Thank you, Lloyd. Good advice. Your recommendation of using a client to push data to a FHIR Server appears to be exactly what is recommended in this IG for sending data from point-of-care devices:
My plan will be to push this data in an “unsolicited” manner. So I’ll just send lots of data there when the device generates it. But can the recipient do what it wants with the data? I mean, I remember reading about the messaging paradigm and how in certain cases the recipient of message could ignore messages if it wanted to. In my case, the recipient might get more data than it really “needs” so can it can pick and choose what data it wants to persist based on its own business logic?
If you POST the data, then the server is expected to store the record and make it available at the URL location indicated in the POST response. However, servers are allowed to purge data according to their own rules, so in theory it won’t need to store it forever. It can also refuse to accept certain posts based on its own business rules.
OK, perfect. This sounds like a good solution. Thanks for the advice. I will probably add some functionality on our side that allows the user to throttle or subsample the data being transmitted also. That way they can “tune” the stream of data to their needs.