FHIR Chat · Best practices for medical devices · implementers

Stream: implementers

Topic: Best practices for medical devices

view this post on Zulip Michael Ilewicz (Mar 12 2021 at 15:12):

Hi all, I am working for a charitable organization working on affordable remote ventilation for COVID-19 and beyond. We want to implement FHIR into our system but as volunteers who are new in the field, we have a few questions we hope we could get help with from this amazing community. I appreciate any hints in the right direction!

  1. We are planning to use the Azure API for FHIR but since this is a new service we wanted to know if somebody has had some experience with it and could answer some questions? For example, we were not able to find out whether the API applies referential integrity checking during creating, updating or patching of resources. We know that the Google API does but could not find anything for Azure...
  2. It would be nice if the device would send the data directly in an FHIR format. We have a few questions about the correct usage of the observation resource with this kind of data. We identified two types of observations that we would want the device to emit. Such that needs to be archived in the long term and waveforms and other temporary data which should be sent at least once a second and should be consumed by the user interface but not necessarily be stored in the FHIR database (except for some sample snapshots). Should such temporary data be sent in an FHIR format?
  3. Is the Observation the correct resource for this?
  4. If so, are there ways to minimize data overhead? We are assuming that the device would create a new observation for each measurement but would bundle related measurements into a single observation and create a separate observation for each measurement that a practitioner can interpret individually. As an IoT device that might even be used in a home setting with poor/metered internet connection, we want to minimize the amount of data sent by the device, on the other hand, we would like to implement the correct encoding for the data to be compatible with other codebases such as LOINC, SNOMED etc. It seems that with specifying these types the payload can bloat up quickly?
  5. Or would another action, such as a patch, be more appropriate especially for this temporary waveform type data?
  6. Would be using deviceProperties be a good way to reduce the payload by storing as much as possible of the static data in the deviceProperty resource?
  7. When applying a patch to a resource we understand that a changelog is used to keep track of all the patches to that resource. Is there a limit to the size of the changelog?
  8. Can a retention period be specified after which changelogs from patch commands are disregarded?
  9. If so would it be a good idea to store the temporary data in a single observation and continuously apply patches to it instead of using the deviceProperty as a method of minimizing payload? Then the user interface could request to read the whole changelog during the initial loading of the page and only process the lightweight patch to update the screen. Does that conflict with any important best practices or implementations of other EHR systems?
  10. How should an encounter be defined for such a treatment. Should one be created frequently, maybe on a daily basis? Or should one be created each time the device boots up? Or for as long as a patient is associated with a device?
  11. We want to store the current configuration of the device in the properties of the device resource. Our device is capable of different modes which under the hood is just a mix of partially fixed device properties and user-configurable device properties. We want to be able to switch quickly between modes without the configuration to conflict between these modes. Currently, we see two ways of doing this, A by creating a codable concept "Mode" which consists of all these properties and then have several Modes as the device properties, or B using a flat structure, i.e. the properties to be mode1property1, mode1property2, mode2property1, mode2property2. Is any of these solutions recommended?
  12. Some of our device properties could be mapped to ISO standard ventilator properties, others can not. Is it worthwhile to use ISO device property codes? Are they in widespread use?
  13. If only some device properties can be mapped, should that be done or should a custom system be used which encompasses all the properties of the device?

Any help would be greatly appreciated!

view this post on Zulip Gino Canessa (Mar 12 2021 at 15:31):

@Brendan Kowitz @Caitlin Voegele

view this post on Zulip John Rhoads (Mar 12 2021 at 20:38):

@Michael Ilewicz You might also want to bring up some of these issues in the Devices stream, where there are people working on similar problems. One question: which standard are you referring to with "ISO standard device property codes"? Maybe ISO/IEEE 11073-10101 Medical Device Communications Nomenclature, or something else?

view this post on Zulip Michael Ilewicz (Mar 12 2021 at 20:43):

thanks @John Rhoads I will bring this up in that stream! yes, that is the standard I am talking about

view this post on Zulip John Rhoads (Mar 12 2021 at 20:52):

@Michael Ilewicz You'll find that some of the authors of that standard hang out in that stream... so we may be biased in favor of it

view this post on Zulip Caitlin Voegele (Mar 12 2021 at 23:37):

@Michael Ilewicz Can you send me an email at cavoeg@microsoft.com? On most of these questions, someone who works on our IoT Connector project would be great to connect with and I can do an introduction.

view this post on Zulip Michael Ilewicz (Mar 20 2021 at 17:13):

Hi @Caitlin Voegele , I have sent you an email, did you receive it?

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -