Hi all - just getting my feet wet in FHIR; I hope this is the right place to ask this kind of question.
I am trying to model the result of an assay from a diagnostic device. I need to include:
Reference to the device that generated the assay
Information about the disposable that was used
Seems like the data should be reported as an Observation. The Observation resource includes a reference to one Device, and here I have two - the machine and the disposable. In a more complex case, I might have submodules in the Device (say, the device can run 4 tests in parallel in independently identifiable modules) and multiple reagents which can be identified by lot # and so want to be tracked along with the assay result.
What’s the right way to use the existing Observation & Device resources to accomplish these things?
Right now, the disposable would typically be conveyed in Specimen.container rather than Device. The reagents would be conveyed in Specimen.treatment. The device that performed the observation would be Observation.device
Observation.device describes the device. Any subcomponents of the device can use the usual DeviceComponent and DeviceMetric models.
Observation.specimen.treatment.additive describes a reagent (for example, a tank of buffer stored in a chemistry analyzer):
…additive.identifier can hold the description of the reagent (e.g. “wash buffer #2”)
…additive.instance.identifier can hold the lot number
…additive.instance.expiry holds the expiration date
Observation.specimen.containter describes the disposable. This is not intuitive, since Container seems to want to describe only simple containers. There’s no lot number or expiry date - even a vacutainer has those. How should that be captured?
When you say “and here I have two - the machine and the disposable” I am assuming the disposable is like a reagent cartridge. I don’t think that the specimen resource is the appropriate resource here unless these disposables are indeed only used to house the specimen. As you stated above the disposable could be a DeviceComponent and the device is the “machine” that houses the disposable. Observation.device links to Device but not to DeviceComponent. Does DeviceComponent meets your needs?
Currently, with an Assay result from my device, I’m communicating configuration information about the device, the submodule of the device, a computer connected to the device that does the communication, and the consumable cartridge. (Let’s leave off the notion that I don’t need to be sending it all with every result - if I break it up so I’m defining some of it in the database in advance, it’s the same structural question.)
My Observation…
…has a “device” which is a DeviceMetric describing the assay, and which…
…has a “parent” which is a DeviceComponent describing the cartridge, and which …
…has a “parent” which is a DeviceComponent that describes the submodule, and which…
…has a “parent” which is a DeviceComponent that describes the main device including a ProductionSpec element for the attached computer as well as one for the device itself, and which…
…has a “parent” which is a Device with the highest level description of the system.
Does that seem right? If I want to send device configuration information every time without creating database entries for, say, submodules, I must nest “contained” elements with the information - submodule DeviceComponent is contained within cartridge DeviceComponent is contained within the Observation. Right?
As a device manufacturer, it’s a bit of a mind-shift to think of everything from the perspective of the specimen - bottom-up instead of top-down, I guess.
One further clarification about consumables. What if a device uses several for an assay? For instance, a large chemistry analyzer might have several tanks of reagent, each with its own lot code. In that case, the structure I’ve set up above:
specimen -> cartridge -> module -> system -> device
doesn’t have a place for info about those reagents.
Does DeviceComponent contain the elements you need. It is “is only applicable to describe a single node in the containment tree that is produced by the context scanner in any medical device that implements or derives from the ISO/IEEE 11073 standard” it does have basic stuff like lot number, manufacturer, expiration date that Device contains?
I’m not sure that reagents are best represented using Device. They seem more like a Substance to me but I haven’t seen this use case put forth before
Here are my thoughts is the DeviceComponent content model is to narrowly focused. Parent Device = analyzer "nested’ Devices whch point to parent = cartridge, attached computer, submodules etc. DeviceMetric which can link to the parent or a nested device.
extension links the substance to the Device.
In FHIR we try have the “newer” resource point to the ‘older’ resource so the Parent Device is the target reference of all the carteridge etc.
Yes, I think the DeviceComponent has what I need to describe the hardware pieces. The parent-inside-child structure forces me into either a linear model of the system, which is challenging if the system has any complexity, or into multiple messages that I then have to reconstruct on the server side.
One thing I’m confused about is the relationship between Device and DeviceComponent. Device seems to be pretty much the same as a DeviceComponent except instead of the flexible ProductionSpec attribute, there are a bunch of hardwired, but optional, specifications: manufacturer, model, etc. If I want to include an additional production specification as part of a Device (e.g. “Software Revision”) I have to either use an extension or just use DeviceComponent to start with. But, the Observation resource specifies that it can reference either a Device or a DeviceMetric - but not a DeviceComponent. Is there a reason for this structure?
Substance can be used to describe a reagent, and as you suggest, I see how an extension could be used to connect the reagent to the Device or a DeviceComponent. I know that the ability to extend in this way is core to the idea of FHIR, but it’s surprising how quickly I’ve arrived there.