Stream: implementers
Topic: Changes to Device Resource
Jose Costa Teixeira (Jun 17 2018 at 16:44):
We'll add a "device.component" to the Device Resource, supporting N levels of devices.
Some questions:
Jose Costa Teixeira (Jun 17 2018 at 16:44):
1. It seems more reasonable to put "device.component" than "device.parent". This way it's the parent that points to eventual children. Is this agreeable?
Jose Costa Teixeira (Jun 17 2018 at 16:47):
2. Device.component can be implemented in different ways:
a) a reference to Device, so if we need to define the component, it is either a contained resource or must exist as an instance
b) a nested Device (i.e. allowing to repeat the whole structure), so that we can, in one single resource, define the components as well. (actually I am not sure it is possible to nest the device root, but let's assume so)
On this point I would lean to a), because while with a) the device component can be contained or autonomous, with b) it can only be contained, i think.
a) is closer to the current design where a device component is an autonomous resource, which seems ok (IRL components may become devices and vice-versa).
Jose Costa Teixeira (Jun 17 2018 at 16:52):
@Eric Haas @Ioana Singureanu @Hans Buitendijk Please help: whom should we ping to comment on this?
Jose Costa Teixeira (Jun 17 2018 at 16:52):
@Stefan Karl
Stefan Karl (Jun 18 2018 at 08:15):
@Jose Costa Teixeira
1. Currently DeviceComponent points to the Device resource. This follows the rule that the reference should be in the resource that is usually created second - e. g. a module (DeviceComponent) that is plugged into a system (Device). The "parent" reference will also make it easier to detect the top-level device in a tree structure by searching for a Device that has no parent. What is the benefit of changing direction?
2. I agree making it a separate resource for the reason you mentioned.
There is a proposal for a merged Device resource at this wiki page, which has been discussed in the Devices workgroup.
Jose Costa Teixeira (Jun 18 2018 at 18:01):
I think we could also have the child pointing to parent, yes. (There was no specific reason for doing the other way around, so we can choose)
Jose Costa Teixeira (Jun 18 2018 at 18:02):
when defining (e.g. in a catalog) or identifying (e.g. in an order or procedure) a device, i think it makes more sense to point to the parent, no?
Jose Costa Teixeira (Jun 18 2018 at 18:03):
i.e. "for this procedure, use this device (and whatever modules you need from it)" seems more natural.
Jose Costa Teixeira (Jun 18 2018 at 18:05):
this may not necessarily require to chose the top-down approach (child pointing to parent). We have to discuss to see which one to use
Jose Costa Teixeira (Jun 18 2018 at 18:09):
we should use the content of the wiki page to check if we are missing something (although that page includes kind and instance).
Eric Haas (Jun 18 2018 at 21:48):
component should point to parent. whether is Device or DeviceComponent.
Eric Haas (Jun 18 2018 at 21:52):
@Jose Costa Teixeira did you look at this I thought was pretty straightforward except for the specialization bit that Brian talked about. Whatever that is should be a) defined so we all know what it is and then b) decide if is in 80% or extension.
Jose Costa Teixeira (Jun 18 2018 at 21:59):
We will merge Device and DeviceComponent. The specialization can be added and the rest we can converge on. I am building a first iteration of the revised resources now.
Craig McClendon (Jul 09 2018 at 16:34):
Can someone tell me what the hierarchy will look like with the Device-DeviceComponent merge for PHD devices?
For a PHD that connects via a mobile application, will the top-level Device be the PHD or the mobile app?
Craig McClendon (Oct 03 2018 at 20:16):
In line with the last question, can someone give me a quick explanation of the modeling of a PHD (personal health device). What I'm looking for is the hierarchy/relationships/resources to represent the PHG (gateway), PHD (device), and Observation. I'd like to know what the prescribed model should look like in STU3, and what it will look like in R4.
@Jose Costa Teixeira @Brian Reinhold anyone?
Thanks!
Jose Costa Teixeira (Oct 03 2018 at 20:18):
sure, can you give an example, to instanciate the resources ?
Jose Costa Teixeira (Oct 03 2018 at 20:18):
(and sorry for missing the last question)
Craig McClendon (Oct 03 2018 at 20:19):
A bluetooth enabled glucometer (PHD), communicating data to a mobile phone application (PHG), sending data to a server which then persists to FHIR.
Jose Costa Teixeira (Oct 03 2018 at 20:22):
ok, first, i I assume your question is NOT "are apps devices?"
Craig McClendon (Oct 03 2018 at 20:23):
well, yeah, I don't have clarity there. Is the app a Device, a DeviceComponent, or is the whole combined "system" simply an abstract Device.
Jose Costa Teixeira (Oct 03 2018 at 20:23):
sure, let's check how it works. but i assume that the app is part of the construct and you don't want to exclude the app
Jose Costa Teixeira (Oct 03 2018 at 20:24):
the nice thing now is that there is no DeviceComponent
Jose Costa Teixeira (Oct 03 2018 at 20:24):
there is a device that can contain other devices
Jose Costa Teixeira (Oct 03 2018 at 20:24):
the Device / DeviceComponent (and now "Device with children Devices") was conceived for a "hierarchical composition" of devices - a cartridge belonging to a device, or a syringe in a perfusion system, or a lead in the ECG...
Jose Costa Teixeira (Oct 03 2018 at 20:31):
The PHD is definitely a Device resource.
If the PHG is doing something with the information and if you want to consider that as a relevant part of the system (I would), and not a passive gateway, you have another device.
Jose Costa Teixeira (Oct 03 2018 at 20:31):
now, the questions for feedback:
Jose Costa Teixeira (Oct 03 2018 at 20:33):
do you see the app as a child of the PHD (i mean is the app something that comes with the device)?
or is the app a more generic aggregator or communication system that handles this and other PHDs?
Jose Costa Teixeira (Oct 03 2018 at 20:34):
You have two devices. Whether the PHG is a device on its own or the PHG is a part of a "configuration" together with the PHD, i would say it depends on how they are designed to work with each other.
Jose Costa Teixeira (Oct 03 2018 at 20:36):
but my first guess would be "PHG / App" is parent device, PHD is another device
Brian Reinhold (Oct 03 2018 at 20:37):
@craig mcclendon Continua has specified guidelines for FHIR uploads. THere is also an implementation guide submitted for ballot based upon DSTU3. This implementation was a best fit scenario given DSTU3. However, with the Device/DeviceComponent merge in R4, a new mapping has been specified and an IG guide for it is in development. I am writing it. You can find the R4 IG on github/HL7. The DSTU3 version is here
https://simplifier.net/guide/pchapersonalhealthdevicedataimplementationguide/home2
The R4 version will be the only mapping that will be part of the final Continua Guidelines.
I have implemented both for all Continua PHDs
Jose Costa Teixeira (Oct 03 2018 at 20:44):
@Brian Reinhold is the IG called uv-pocd?
Brian Reinhold (Oct 03 2018 at 20:44):
@Brian Reinhold is the IG called uv-pocd?
No. That is PoCD devices (Point of Care). It is called PHG
Its a work in progress, most of it is done.
Oh yuulk. That's just how to build it which is a major pain. I will attach a zip file that you can view in any browser (after unzipping)
Brian Reinhold (Oct 03 2018 at 20:49):
hope that worked.
Craig McClendon (Oct 03 2018 at 21:02):
Thanks guys. @Brian Reinhold - I'm still confused on the proper way to represent things in STU3. The Continua guidelines show an example of a PHD represented as a Device, and a PHG represented as a Device. And the "Phd Coincident Time Stamp Observation" shows an Observation referencing a DeviceComponent, which is possibly a typo?
Craig McClendon (Oct 03 2018 at 21:06):
I can see a few ways to model it.
App/PHG (Device)
PHD (DeviceComponent)
DeviceMetric (dummy resource to contain relationship)
Observation
The above is problematic for many reasons.
A variation:
App/PHG (DeviceComponent)
PHD (DeviceComponent)
DeviceMetric (dummy resource to contain relationship)
Observation
More problematic.
Or more simply:
Device (an abstract combination of the PHD and PHG)
Observation
Simple, but is it correct?
Or use extenentions on Device to mimic the R4 modeling?
Craig McClendon (Oct 03 2018 at 21:09):
^zulip took out my formatting, but assume the resource under another resource reference it in the above - ie a parent-child hierarchy
Brian Reinhold (Oct 03 2018 at 21:09):
Thanks guys. @Brian Reinhold - I'm still confused on the proper way to represent things in STU3. The Continua guidelines show an example of a PHD represented as a Device, and a PHG represented as a Device. And the "Phd Coincident Time Stamp Observation" shows an Observation referencing a DeviceComponent, which is possibly a typo?
@craig mcclendon That is because there were many problems trying to map PHDs to FHIR and there were many trials. You are seeing the results of that confusion.
In the end, before R4 came out, the PHD and PHG were represented in the DeviceComponent ONLY. Anything else is an error or something from development and trials. You may not have the final Continua Guidelines.There is an Android application in the playstore LniPlugfestPHG which does the final DSTU3 version of the FHIR upload. Supports HDP and USB 20601 devices and BTLE.
R4 merged DeviceCOmponent and Device and the DeviceCOmponent is gone. New elements were also added in R4 much better for PHD.
Craig McClendon (Oct 03 2018 at 21:17):
Appreciate the help..
If I need to model this in STU3, would I be very wrong (or run into problems) if I:
a) Combine the PHD and PHG into a single Device resource
or
b) Add an extension to Device to mimic the R4 Device.parent attribute so I can represent both PHG and PHD as Devices?
Craig McClendon (Oct 03 2018 at 21:20):
.. to add to that, the DeviceComponent-only representation would be problematic for something like a smart inhaler or glucose pump which is administering medication as well as producing observations.
Brian Reinhold (Oct 03 2018 at 21:27):
@craig mcclendon If you want to do your own mapping you can do what you want. The problem with FHIR in DSTU3 was that the System-Model information (manufacturer name and model number) were in the Device and the Production-Spec information was in the DeviceCOmponent. IN the last versions of DSTU3 some fixes were made in the DeviceComponent so a PHD could be mapped ENTIRELY into the DeviceComponent without extensions. The PHG was mapped by assuming it had the same properties as a PHD in a MDS (which it really doesnt have).
In the COntinua mapping, it is critical to report everything the device transmits by standard protocol. The last versions of DSTU3 did this with the addition of the DeviceComponent.properties element. Before that we used extensions in the DeviceComponent to model what would be in the properties.
In the LNIPlugfestPHG you can set the FHIR to 4 different versions (the R4 is not the current R4 but the pre-merge case). Extensions are used in all the options prior to what is listed as R4 in the app (really 3.1.0).
All this confusing crap goes away in 3.5.0/3.6.0
Brian Reinhold (Oct 03 2018 at 21:30):
Here is a 3.1.0 upload of a BTLE Nonin PulseOx
Craig McClendon (Oct 03 2018 at 21:48):
So just to be clear, in R4 will the PHG be the parent Device and the PHD the child Device?
Craig McClendon (Oct 03 2018 at 21:53):
hmmm, but that is problematic if a user sync's a PHD through two different PHGs.. for instance if they have the same app on a tablet and phone. You'd need to duplicate the PHD Device to capture both relationships if it is the child.
Brian Reinhold (Oct 03 2018 at 21:54):
Still up in the air.
I think what will be decided is that the PHG will be referenced in the OBSERVATION and not the Device. There will be no parent/child relation, because there is not. THere is another good reason NOT to do that. If the PHG is made a parent of the PHD, then every PHG that uploads the Device resource for a given PHD will need to create its own resource that will differ only in the parent element. Same physical device with two resources. Not good. Since there is no way to use any existing element in the Observation to do this, the PHG will be in an extension. That will be the only extension in the PHD profile.
@craig mcclendon I am at an HL7/FHIR meeting right now and they are shutting down. Will have to continue this later.
Craig McClendon (Oct 03 2018 at 21:58):
That makes most the sense on quick inspection. The Observation should reference the PHD and the PHG separately.
Raheel Sayeed (Apr 16 2019 at 15:12):
Hey @craig mcclendon, is there a sample observation resource or documentations explaining this? I'm trying to do something similar, An App that packages data from the phone (device)'s sensors into an Observation.
Craig McClendon (Apr 16 2019 at 15:52):
@Raheel Sayeed - I am not sure what the current PHD profile has in it. Would be worth finding out. @Brian Reinhold ? But what I am currently doing (in STU3) is creating two Devices, one for the sensor (PHD) and one for the phone/gateway (PHG). I have Observation.device reference the PHD. And I add a custom extension to Observation to reference the PHG. (If the devices group has defined a standard extension for that, it of course would be preferable to use that instead making up your own. ) I do not have the two Device resources reference each other in any way. The only relationship between them is linked through the Observations.
This approach has the downside that you cannot search for Observations from a particular PHG through FHIR directly. But for my cases the PHG association is mostly just for provenance/audit purposes.
Raheel Sayeed (Apr 16 2019 at 16:06):
Yes, that's what I'm looking at. For some clarity that's specific to case:
if Observation.value is from the phone sensor, then the phone itself is PHD. And there's no need for a PHG.
--or--
because I'm using an app (running on the same phone), would the app then become a PHG?
Craig McClendon (Apr 16 2019 at 16:21):
I'm not a definitive expert, but I think it could still be useful to separate the two. Changes to the application version, for instance, could affect the way the data is interpreted/processed. So you may want that information divorced from the sensor. It also might make your information models more uniform if in the future you collect data from external devices communicating through an app on the phone. But there are tradeoffs, and you could probably model it either way.
Raheel Sayeed (Apr 16 2019 at 16:36):
Makes sense. There are also complexities where different apps use the same "embedded 3rd party frameworks" that are responsible for harmonizing sensor derivatives. In this case, the 3rd framework/publisher is a reliable PHG. (this is true in my case)
Brian Reinhold (Apr 16 2019 at 21:08):
In the PHD world where the PHD is a separate entity from the PHG, the important role of the PHG is handling time stamps from the PHD (which are often pretty bad). They are both corrected (if in error) and given an offset to UTC. That allows the measurement time stamp to be sent anywhere and one knows when it is.
In your case the phone is both PHD and gateway. In that case, the 'PHD' is probably well synchronized to UTC and that can be indicated in the PHD Device resource. I do not think you need a PHG Device resource; just be sure to indicate the type of time stamp (base offset time) and the time synchronization protocol. This will tell the reader of the Observation that the device is synchronized to UTC and thus so are the measurement time stamps.
Last updated: Apr 12 2022 at 19:14 UTC
