Stream: Orders and Observation WG
Topic: GF#15596 Request cardinality of Device.type be changed from
Eric Haas (Feb 21 2018 at 21:29):
GF#15596 I'm finding this pretty non persuasive:
to clarify: is the proposal to enable profiling device - because for profiling the cardinality of the element doesn't matter - just reuse the same profile for mulitple types. or is it to enable a way to represent multiple devices in a single Device instance - that is not going to work since all the resource attribute point to a single device.
@Martin Rosner ?
Lloyd McKenzie (Feb 22 2018 at 03:36):
My reading of the proposal is that a single device might simultaneously be of multiple types. E.g. Heart rate monitor + Pulsoximeter. The question is how this relates to the Device/DeviceComponent division. Do we have 0..* on Device.type or do we set Device.type to "multi-function device" and then list the types in DeviceComponent? Having two ways to convey the same information isn't prohibited in FHIR, but we need to think carefully before we allow it and confirm that it's really necessary.
Eric Haas (Feb 22 2018 at 04:43):
I thought the whole device, device component, device metric model was all about representing the attributes for each modality. If you don't care then just use type = "multifunction device" i.e 0..1.
Lloyd McKenzie (Feb 22 2018 at 04:47):
Well, the point is that they do care. They want to say "This device is a heart rate monitor" and "This device is a pulseoximeter" - for the same device. The question is what's the right way to do that - and if we should support two ways of doing that.
Eric Haas (Feb 22 2018 at 05:16):
There are already type codes for multicomponent devices. will await further input. A diagram would be nice...
Eric Haas (Feb 27 2018 at 21:26):
submitter has provided a powerpoint summarizing there requested changes in the tracker
Eric Haas (Feb 27 2018 at 21:29):
Here are a couple of screenshots:
What the submitter would like Device to do:
Screen-Shot-2018-02-27-at-1.27.14-PM.png
Eric Haas (Feb 27 2018 at 21:30):
see the tracker for more details..
Eric Haas (Feb 27 2018 at 21:37):
Here is my immediate feedback:
Would like more detailed model of IEEE 11073 PHD or a simple nonFHIR model of what is being displayed in Slide 5. I am still not clear why device replaces devicecomponent for the the different functions of a device as displayed in Slide 5 and why device isn't the top level instead of DeviceComponent. I would seem to me that the proposal just replaced DeviceComponent with Device in essence getting rid of DeviceComponent as a redundant layer?
And I still don't get why type would be 0..* just use a concept for 'multifunction device Z', what does listing out 'device Z with function A', and 'device Z with function B' buy you?
An alternative is to use some post- coordinated concept.
We need to look how these changes would affect the other use cases for Device as well.
Lloyd McKenzie (Feb 27 2018 at 21:49):
The diagram posted doesn't show DeviceComponent at all...
Eric Haas (Feb 27 2018 at 22:38):
see the tracker for more details.. that is just one screen shot from the powerpoint
Eric Haas (Feb 28 2018 at 18:36):
Here what I think the best solution would be if the desire is to really harmonize the two. this is a more radical change than the radical change suggested by the commenter.
- get rid of DeviceComponent and merge with Device
- Nest Devices
Eric Haas (Feb 28 2018 at 18:36):
(deleted)
Eric Haas (Feb 28 2018 at 18:36):
Screen-Shot-2018-02-28-at-10.32.51-AM.png
Eric Haas (Feb 28 2018 at 18:39):
still can't understand why need type = 0..*. The way I look at it is if you have a bag of groceries your code is bag of groceries you don't list each item in item in the bag.
Eric Haas (Feb 28 2018 at 18:41):
(kudos to ClinFhir once again for letting me visualize this so easily)
Eric Haas (Feb 28 2018 at 20:24):
Screen-Shot-2018-02-28-at-12.19.19-PM.png
Eric Haas (Feb 28 2018 at 20:25):
and after rereading the PHD draft IG think that what is really wanted is a way to represent Specializations in a device. so sounds more like an new element than Type 0..*
Brian Reinhold (Mar 01 2018 at 11:29):
Eric,
That would be the ideal solution in my opinion. There is so much overlap between Device and DeviceComponent that they do not deserve to be independent resources. If the two were merged, then the Device would get parent and child elements and one could use that to establish any kind of hierarchy one wants. The hard part as I have seen it for Personal Health Devices (which are a single device) has been the lack of a ProductionSpecification in the Device.
Also, about multiple specializations in a PHD. In some sense, the definition of a specialization is somewhat arbitrary and artificial. An example is the ECG specialization which is used as a heart rate monitor. But the monitor uses some input from the user (weight, age, sex, etc.) and the device calculates calories burned based upon those inputs and the heart rate. However, the calories consumed measurement is not part of the ECG specialization, it is part of the Cardiovascular specialization. So this device reports two specializations.
Another case is a weight scale and body composition specialization. Both have weight measurements and the BCA needs that weight value to do its thing. So a BCA is often a scale you step on barefoot so little electric pulses go through you to get the BCA measurements (such as percent of body fat). Here is another potential multi-specialization device in the PHD world. In both cases, it is a single device.
In the much more sophisticated PoCD world, the Device might be a controller, like a Vital Signs Montor. But it controls sub-components that may even come from different companies. These sub-components might be individually responsible for measuring a single vital sign; heart rate, temperature, breathing rate, SpO2, etc. Those sub-components may be exchangeable pieces of hardware and the PoCD model is capable of expressing and reporting that. No so in the PHD world. All measurements are reported as coming from a single unit and the receiver of the data only knows what the measurements are and they all come from a Device with the same fixed properties.
A couple of years ago a submitted a request for the merger of the Device and DeviceComponent as a way to solve all PHD and PoCD mapping issues without losing anything that the Device already had. Since many of the elements in both are the same, the merger did not add many new elements.
Eric Haas (Mar 01 2018 at 15:59):
@Brian Reinhold The ProductionSpecification really bothers me because in Device we enumerate may of the these as inline elements so what else in the 80% that needs to be an element and how do we avoid duplication or putting in ProductionSpecification when there is a perfectly good element.
Eric Haas (Mar 01 2018 at 16:02):
I am glad we are in agreement but I am assuming that there is not universal agreement - Will need cross WGs coordination and pretty sure will be hard to do before R 4
John Rhoads (Mar 01 2018 at 19:03):
@Eric Haas @Brian Reinhold Eric, is your proposal to do away entirely with DeviceComponent or only to leave it out of the PHD model? Accomodating PHD needs fully in Device is a good thing, but trying to completely collapse DeviceComponents into Device would throw over Point-of-Care Device (PoCD) modeling and practice in a big way. A complicated PoCD device (and most of them are fairly complicated) is represented by a hierarchy of related DeviceComponents, some of which make no sense to represent as Devices. And hanging dynamic attributes off of Device seems inconsistent with its intended use, no?
John Rhoads (Mar 01 2018 at 19:14):
By dynamic attributes I mean things like measurement state. An individual module or measurement can be turned off at the device by clinicians for reasons like moving leads or transducers on a patient. Software trying to determine why observations aren't coming in would want to be able to find that out.
Eric Haas (Mar 01 2018 at 21:36):
The suggestion is to Merge them reproducing DeviceComponents elements in Device and doing away with the DeviceComponent. Conceptually it sounds to me that there is not a bright line between the Device and DeviceComponent or we would not be talking about this. Using a single resource that sometimes is the device containers or sometimes a component and sometimes something in the middle seems like a better idea than duplicating a bunch of elements in Device ( as the tracker suggests ) and creates two essentially identical resources. I haven't explored this idea much beyond this chat but would like to discuss further. Originally Device was intended to be a static administrative thing. Maybe is to ambitious to have a single resource cover all device use cases? but here is pretty complete picture of the merge resource ...
Eric Haas (Mar 01 2018 at 21:39):
deviceComponent-DeviceMerge.png
Eric Haas (Mar 01 2018 at 21:40):
Can we discuss after HIMMS? or during if you are there?
Brian Reinhold (Mar 02 2018 at 09:59):
@John Rhoads I think the idea is to merge them so that they can represent either. All fields that exist in the DC would now be present in the Device, and with the merger, the DC would add 'child' and 'parent' elements. The Device would be the static entity at the top of the hierarchy. IT would have no parent. A Device with a DC concept would always have a parent and either point to another Device with a parent element or a static top-level Device with no parent. One could even make the requirement that a Device with lastSystemChange and operationalStatus entries must have a parent element. And that a Device without a parent element shall not have lastSystemChange and operationalStatus entries. As I understand it, these two are the only dynamic entries; everything else is present on a static Device or is already present in the Device. At one time 'lastSystemChange' was required in the DC but taken out so PHDs could use it only to get the productionSpec. A compromise but in so-doing knocked a piece of the 'dynamicness' of the DC down a notch. One could bring it back by requiring the field if there is a parent element.
The combination of the two has the advantage of efficiency since so much is otherwise duplicated between the two. That simplifies IG guides so they don't have to specify which of the duplicate entries is populated.
Well, that was the idea in any case.
Stefan Karl (Mar 02 2018 at 14:07):
I agree that there is some overlap between Device and DeviceComponent, and there will be more with the addition of productionSpecification. As suggested, the point-of-care device model defined in the PoCD IG could also be realized by profiling Device resources for the MDS, VMD, and Channel layers (constraining unneeded elements to 0..0). It would even solve the problem with multiple UDIs for devices with physical sub-systems.
Currently the Device resource can be used as "entry point" for searching and reconstructing the PoCD structure from resources on a server. DeviceComponents can be found by looking for the source reference. Using Device only will need clear guidance how to distinguish between the overall device representation and purely logical components.
Merging Device and DeviceComponent would be a big change for the current PoCD model. If we can get to a clean and aligned model for both PHD and PoCD, I'd consider it worth the effort.
John Rhoads (Mar 02 2018 at 19:45):
Needs some discussion. Unfortunately I won't be at HIMSS, nor I think will either of the Stefans, or Brian, so let's find another venue (might "Devices on FHIR" conference calls Wednesdays 9:30 ET work?). As Stefan K says, it would be a big change for PoCD model, but it might be worth doing for a couple of potential benefits. I'm surprised that people who are not so much in the device world seem to be willing to consider repurposing Device from being mainly administrative to something with two divergent uses and bundles of functionality that, you have to admit, are pretty different and maybe involve some pretty contorted "80-20" rationalization. I'd also think some current users of Device would find the ground shifting under them in surprising ways. However, it's not for me to say! I'm willing to listen.
John Rhoads (Mar 02 2018 at 19:48):
@Eric Haas @Stefan Karl @Brian Reinhold
Brian Reinhold (Mar 02 2018 at 19:56):
This should not bother current Device users, as all the introduced fields and merged fields are optional. It won't even be a breaking change. Software that can work with the current Device will work with this merger as it does not change anything in the current Device. The only breaking change is outside of the merger but would be changing the Device.type to 0..*.
OO does not particularly like that but would prefer adding a new element called specializations with 0..*. PHD is certainly happy with that. The Device.type might then be "PHD" and then the specializations would be in the new element.
One has to also remember that the Device is only at level 2 which means that development is still expected as it gets used and tested.
Jose Costa Teixeira (Mar 02 2018 at 19:58):
Late to this discussion, but just to let know that afaik there is a chance that we'd reform/retire DeviceComponent
Jose Costa Teixeira (Mar 02 2018 at 19:58):
(right?)
Jose Costa Teixeira (Mar 02 2018 at 19:59):
@Stefan Karl What is productionSpecification?
Jose Costa Teixeira (Mar 02 2018 at 20:08):
There is so much overlap between Device and DeviceComponent that they do not deserve to be independent resources. If the two were merged, then the Device would get parent and child elements and one could use that to establish any kind of hierarchy one wants.
Yes, that is the thing. Device can have a component that is another device. A Device Matryoshka
Jose Costa Teixeira (Mar 02 2018 at 20:12):
Here what I think the best solution would be if the desire is to really harmonize the two. this is a more radical change than the radical change suggested by the commenter.
* get rid of DeviceComponent and merge with Device
* Nest Devices
Yes, we discussed this path this week
Martin Rosner (Mar 02 2018 at 20:19):
I think it's worth discussing in DoF given the feedback from OO. And indeed since maturity is at level 2, this is a good time to harmonize across all interested parties (administrative or otherwise). As the lines between PHD and PoCD become increasingly blurry it is in all our interests to come to a common model - to that end I am not surprised of the effort to do so. We can discuss further on the DoF call but for @Eric Haas that will be 6:30am Vegas time next week.
Eric Haas (Mar 02 2018 at 23:42):
sure I will try to make it. Which day? And I admit I'm only looking at this issue from the perspective of the tracker and the intent to harmonize the two. I am not a medical device expert and trying to understand the use case. It is a huge challenge to try to represent everything from a toothbrush to a complex medical monitoring device in a single resource. There are obvious trade-offs.
Eric Haas (Mar 02 2018 at 23:54):
RE: "It would even solve the problem with multiple UDIs for devices with physical sub-systems." There is separate tracker GF#13965 which is also making the suggestion that a component Device point to a parent Device.
"Between the Device and DeviceComponent, there are a number of ways in which UDI information can be represented for these more complex, composable systems. For example, there could be a Device instance with UDI for the top-level information and then one or more DeviceComponents for the subcomponents, some of which may also have UDI information. Alternatively, a new relationship data element could be added to Device (e.g., parent) to represent "is a component of" and thus capture the additional UDIs. "
I have not dealt with this one directly : @Jose Costa Teixeira or @Hans Buitendijk I'm sure this discussion ties into that one as well.
Jose Costa Teixeira (Mar 03 2018 at 00:47):
it does. It seems we will benefit from getting rid of deviceComponent and soon
Eric Haas (Mar 03 2018 at 00:48):
Well ... is a discussion point. The people using and making Devices need to agree as well.
Jose Costa Teixeira (Mar 03 2018 at 00:50):
yes. i am just stating that imo we made life harder, the sooner we have some more solid resource set, the better
Stefan Karl (Mar 03 2018 at 16:59):
@Jose Costa Teixeira productionSpecification is a complex element that carries hardware- and software-specific information like product/part number, serial number, and hardware/firmware/software versions. There can be multiple (0..*) entries, which have a specification type with extensible binding, an optional identifier, and the specification string itself. The definition is taken from the ISO/IEEE 11073-10201 (PoCD) and -20601 (PHD) standards.
The ability to represent multiple versions is quite important. Even simple electronic devices will have hardware and firmware version. In many cases there are several pieces of software with independent versioning, e. g. boot loader, operating system, and application software modules. This is what the optional identifier is intended for. Centralized device management and software update servers will need this information at a detailed level.
We already identified some overlap between the productionSpecification definition and what's already in the Device resource - see last slide in Martin's presentation attached to GF#15596: Serial number is in Device.identifier and should be removed from the specification-type ValueSet. Device.version should be covered by the (more specific) productionSpecification entries.
Eric Haas (Mar 03 2018 at 18:42):
@Jose and @Stefan I listed the prod specs out in mashup logical model combining the two above. As Brian mentioned you could easily profile the component from Device if we were to go this route.
Jose Costa Teixeira (Mar 03 2018 at 20:11):
@Eric Haas Yes, I think that is closer to what we need. Is this taken from our UDI call last monday?
@Stefan Karl I was afraid that productionSpecification was a new resource. in Catalog discussions, we have found a need for additional attributes like this. So I do think we need these attributes. However, we should not mix Kind and instance in a same element.
Serial number, firmware version etc. are on the Instance, not on Kind.
Product and part number are on Kind, not on instance. Think GS1's Device Identifiers (Kind) and Production Identifiers (Instance).
So I think that a) merging DeviceComponent into device and b) handling Kind and Instance appropriately will give us what we need. Having a flexible "productionSpecification" seems to be quite close to what we had in entryDefinition.
Martin Rosner (Mar 06 2018 at 14:34):
Wednesday/tomorrow.
Martin Rosner (Mar 06 2018 at 14:37):
sure I will try to make it. Which day? And I admit I'm only looking at this issue from the perspective of the tracker and the intent to harmonize the two. I am not a medical device expert and trying to understand the use case. It is a huge challenge to try to represent everything from a toothbrush to a complex medical monitoring device in a single resource. There are obvious trade-offs.
Wednesday / tomorrow - @Eric Haas
Eric Haas (Mar 06 2018 at 16:32):
Can somebody explain to me what a "Specialization" is in simple non-10073 insider terms. When I hear it and read about it I think of it *not * as a type but a set of attributes that describes a function OR a subtype that describes a specific capability. For example to me the type is a fitness band or a Pulse OX and a specialization is the HR functionality.
So when I look at representing this term 'specialization' in FHIR It could be any on of these things...
- a translation on the type
- a set of capabilities listed as codes
- as types (fitness band, hrt rate monitor)
- as a new element specialization
- a set of Device profiles.
Brian Reinhold (Mar 07 2018 at 13:09):
@Eric Haas A specialization is a refinement of the base standard, kind of like a profile on a resource in FHIR. The general resource has lots of options which a profile limits and defines to describe its use case. THe base standard 20601 is a generic means of representing (almost) any medical device; the device information and the types of measurements. A specialization, like the Blood Pressure specialization, restricts the generalized attribute values and objects to specific values; for example it specifies two measurement objects (equivalent to FHIR resources), one to represent the blood pressure and another to represent the pulse rate. Within each of those objects the attributes (equivalent to resource elements) are specified to describe a blood pressure measurement etc. That might be a little too 11073 but the corresponding FHIR model (which you are very familar with) should help.
Brian Reinhold (Mar 07 2018 at 13:19):
@Eric Haas "Production specification' As I see it the Device has only one inline element and that is the version. THe Production Spec has hardware, software, and firmware versions, all which are different. The Production Spec does NOT normally include the manufacturer name and model number. Those are in the SystemModel attribute of the PHD. For the PHD IG guide, I had to put those two fields in the Production spec since there was no place for them in the DeviceComponent. THis too has always seemed weird to me since the PoCD specification has a SYstemModel attribute for BOTH the MDS and VMD. My ideal mapping would be MDS to Device and VMD to DeviceComponent. But lets face it, they are both Devices so in the end fields one needs to describe them are going to be mostly the same!
THe UDI is also making its way into PHDs. ITs not there yet, but its all a matter of time. THus we will need that in the DeviceComponent, too. This is why I like a merger.
Eric Haas (Mar 07 2018 at 17:33):
thanks for the explanation of specializations, that is going to be hard to document but necessary. updated the proposed merged resource here: http://clinfhir.com/logicalModeller.html#8tbfk
Last updated: Apr 12 2022 at 19:14 UTC
