Stream: implementers
Topic: Representing a piece of software in FHIR
Morten Ernebjerg (May 20 2021 at 12:22):
I though I knew the answer to this but now I'm not so sure: how to represent a piece of (medical) software in a resource. Specifically, I want to transmit details about a medical app which produced a set of resources. I thought it was done with Device, but looking at the (R4) documentation I didn't find any mention of this use case (the one place the word "software" appears is in describing software running on the device). Is that the right resource and, if so, are there examples out there where this is done?
Lloyd McKenzie (May 20 2021 at 13:14):
Device is absolutely the right place. (Feel free to submit a change request to have this made clearer.) What sort of details are you struggling with?
Morten Ernebjerg (May 20 2021 at 13:25):
(deleted)
Morten Ernebjerg (May 20 2021 at 13:30):
Thanks @Lloyd McKenzie! Now that I known I'm in the right place, I think most elements of the data will be OK (will probably put in a change request for the documentation, though). One thing I don't quite see is what would be sensible values for specialization.systemType and version.type for indicating FHIR compatibility and semantic versioning, respectively (though for the version I suppose one can leave out the type).
Lloyd McKenzie (May 20 2021 at 13:56):
Right now, there aren't codes provided at all. Feel free to provide feedback on the resource
Morten Ernebjerg (May 21 2021 at 12:47):
Opened FHIR-32681 suggestion some updates to the documentation.
Craig Newman (May 21 2021 at 13:39):
@Morten Ernebjerg - wondering if part of what you want to convey is the software install date. I've kind of convinced myself that Device.manufactureDate might be appropriate (equating an instance of software (like an EHR) with an instance of a device). If you're looking at the same concept, I'd be interested in what you are thinking.
Morten Ernebjerg (May 21 2021 at 14:47):
@Craig Newman I was actually looking at storing information about an app in general rather than a specific installation of it. I must admit I didn't think much about this distinction yet, but now that you mention it, it looks like I should actually be using DeviceDefinition for that! @Lloyd McKenzie is that the correct way to represent generic app vs. specific installation on a given system? It seems that one cannot reference a DeviceDefinition instead of a Device from e.g. Observation. So how can one report that a measurement was made with a specific type of device/software without specifying a specific instance/installation?
Lloyd McKenzie (May 21 2021 at 15:26):
The split of Device into two resources is new. If definition isn't available, don't worry about it and just use Device.
Craig McClendon (May 21 2021 at 15:43):
My opinion - Device and related resources seem to have been in flux for years. For example, all the docs still reference DeviceComponent which is no longer even in the spec. Ultimately though, you probably want to reference the device/software elsewhere, and Device is your best bet for that as it has many resources which can reference it. We've been mostly just trying to hack what we need into Device and make do with it.
edit/correction: the R4 specs still reference DeviceComponent. It appears the latest build specs have been cleaned up.
Morten Ernebjerg (May 25 2021 at 09:47):
@Lloyd McKenzie @craig mcclendon Thanks lot for your input, I will stick to Device, then - I can work with pragmatism :wink:
Last updated: Apr 12 2022 at 19:14 UTC
