Stream: implementers
Topic: Time delays
Raja Moiz (Sep 17 2021 at 04:46):
Hi Everyone,
Can anyone let me know how much time is required to receive a message from a medical device to fhir server?
If we have more than 1 device, should 1 device wait for other to send message first or both devices send message on same time
Devices sends message by its own, or Fhir server require to send a message to recieve a message ?
Raja Moiz (Sep 17 2021 at 04:49):
exactly what I want is the time taken to send or receive a message from device to fhir server, having one device or having 10 devices
René Spronk (Sep 17 2021 at 08:42):
Typically a device would send any data it has whenever it's ready. A server usually sits there any accepts any (concurrent) inbound feeds.
John Silva (Sep 17 2021 at 12:27):
In critical care environments there can be 10 to 100s of (patient monitoring) devices sending data (e.g. Observations - HR, BP, Temp, etc.) to a FHIR server. Whether or not the FHIR server can handle this becomes a question of the scaling of the FHIR server's resources, e.g. CPU speed/allocation (on cloud), RAM, DB performance, network bandwidth, etc. So your question seems to become a one of analyzing the performance capabilities of the FHIR server you use (or are intending to use). It would probably be helpful to run some performance tests on your chosen FHIR server and collecting metrics to see how it handles increasingly higher loads, e.g. more FHIR message posts per minute. If you are using a cloud-based FHIR server it probably supports scaling in CPU/RAM/Disk speed as well as dynamic scaling of services to handle more requests.
John Moehrke (Sep 17 2021 at 12:36):
yes, Medical Devices should worry about this... But, the technology (http REST) has been implemented (systems-design) into many solutions that have shown to have transactional scale unimaginable (e.g. insert here all the internet focused business like amazon, facebook, google, netflix, etc)
John Moehrke (Sep 17 2021 at 12:38):
capability to scale, but not guaranteed to have been implemented right.. so there are design requirements that the medical-device community need to get strict about. These are not going to be something that an interoperability specification (FHIR) should specifiy, but are the kind of things specific use-cases should when needed.
John Silva (Sep 17 2021 at 14:06):
True, many other industries have scaled to support high (millions/sec) http REST transaction rates. However, I suspect many FHIR implementations have been focused on the typical loads of EHR data, e.g. maybe 10s of Labs/patient/day, 100s vital signs/patient/day, 5 orders/patient/day, etc. a much smaller transaction load than medical device data. For example, I know of patient monitoring data feeds that can send in vital sign data of 5-10 elements (FHIR Observations) every 30 seconds per patient/per bed. In a typical critical care unit there tend to be at least 10 patients (beds) producing this high frequency data. I don't believe (m)any FHIR severs have been brought to bear to address this transaction demand.
Wasn't there a FHIR effort to look into FHIR at scale? Ah, yes, the ONC "FHIR at Scale Taskforce" although I'm not sure this effort is about 'input data scaling' but scaling across multiple FHIR servers (national/regional FHIR aggregation needs)?
https://oncprojectracking.healthit.gov/wiki/pages/viewpage.action?pageId=43614268
Last updated: Apr 12 2022 at 19:14 UTC
