Stream: implementers
Topic: Modeling relation between web API and user/wearable device
Morten Ernebjerg (Jul 06 2021 at 08:27):
I'm looking at a use case where data originally coming from wearable devices are pulled from a centralized Web API offered by a data aggregator, often the device manufacturer itself (such a Web API is offered by e.g. FitBit). It seems clear that one can model the API itself as a Device, as discussed in e.g. this recent thread. However, I unsure about two particular details and am looking for existing guidance or experience (apologies in advance for the length! - I wanted to show the options I have considered):
1. Modeling individual user accounts The data retrieved from the API for a given patient really comes from a corresponding user account that is accessible via the API. The account would be identified by e.g. a user-id also used when accessing the API. So I am wondering if/how one could use Device to represent a single user account accessed via the API, e.g. by somehow including the user ID or equivalent information. I looked at a few options but did not really find anything that seem solid (short of custom extensions, of course):
Device.patientdoes not work since it seems to be meant for indicating that a device is attached to a given person.- Having a hierarchy of devices using
Device.parentdoesn't seem attractive either, since an account is not really a "sub-device" of the API itself. - The DeviceUse resource does not seem appropriate either since what we want to model is not the usage of the API but rather a particular user account exposed by the API.
- In some cases, the user-ID might appear in a systematic way in such a way that one could put a user-specific URL in
Device.URL([base URL]/[user-id]/someDatatType/1--> user URL =[base URL]/[user-id]). That, however, would be hard to understand for data receivers and depends on the API design. - The closest match for account information seems to be
Device.property, but I cannot really tell from the documentation whether that is appropriate and what one could use as codes/type(ForDevice.property.type, it looks like there is a binding, but what appear to be the binding indication - "DeviceDefinitionPropetyCode (Extensible)" - is not linked to a value set). - One could consider making the API itself a DeviceDefinition and letting each user account be represented by a device linking to the DeviceDefinition in
Device.definition, but one still has the problem of indicating which account/user is meant.
2. Modeling physical devices whose data is aggregated by API: The API might also expose information about the actual physical device the data came from, either at the level of the individual measurement or by indicating which devices are supplying data to the aggregation service. Each such physical Device could also be modelled as a Device. But how can I indicate the link between the device-Device and the API-Device? Again, Device.parent does not seem appropriate, but I see not other way of directly linking two Device resources. Or would one maybe not link them at all but instead just attach both to a given measurement, e.g. point Observation.device to the physical device and use the gatewayDevice-extension to point to the API? Not sure if the latter is even correct, the extension documentation does not really say what information it carries, only that it can also go in Provenance/AuditEvent.
Lloyd McKenzie (Jul 06 2021 at 15:27):
The notion of user account has been explicitly defined as outside FHIR's scope as there are other RESTful standards for representing the notion of 'user', 'user account', 'access permission', etc. (@John Moehrke I was expecting to see a reference to this standard on the security page but didn't. Given it's a FAQ, would it be worth including such a reference?)
Within FHIR, an API is typically represented using EndPoint. Users authenticate to the API over OAuth. The API itself doesn't manifest in data except perhaps in Resource.meta.source, though it can also show up in Provenance. If users manifest in FHIR, they typically show up as Patient, RelatedPerson or Practitioner (if human) or as Device if a system.
Observation.device is the physical device used to make the measurement. Observation.meta.source would be the system it came from.
Cooper Thompson (Jul 06 2021 at 15:29):
In cases where users do need to be represented in FHIR, RelatedPerson is one option. RelatedPerson supports both "self-access" users, where the user is the patient, but also delegated access, where a parent might be managing data for a child.
Cooper Thompson (Jul 06 2021 at 15:31):
I do very strongly encourage folks not to mix up the patient and the user. Those can be two different people, and if you use the same property (e.g. Device.patient) for both, then you are designing yourself into a corner where you don't support any sort of delegated access, which means you basically can't work with pediatric organizations, and can't support a decent amount of complex care scenarios for non-pediatric areas too.
John Moehrke (Jul 06 2021 at 16:18):
User account management is something that would span many data domains, where FHIR is just one data domain. For example the other domains might be Human Resources). The main impact of a user to FHIR is by way of the user identifier as a FHIR Identifier (Patient, Practitioner, RelatedPerson, Person, etc). This use of Identifier datatype is the linkage between the user account management domain and the FHIR domain. The interaction with user authentication would typically be through OAuth, specifically OpenID-Connect.
John Moehrke (Jul 06 2021 at 16:21):
There is a RESTful standard api defined -- SCIM -- https://datatracker.ietf.org/doc/html/rfc7644
This has not received enough interest to be put into the FHIR security pages as a recommendation. I understand that Grahame has leveraged this in his reference server.
Typically user management is done by way of a user management platform that is more broadly adopted by an organization, examples would be Active Directory, Apache Directory, Open LDAP, or an external OAuth provider like Google/Facebook etc.
John Moehrke (Jul 06 2021 at 16:44):
also, here is Grahame on the topic http://www.healthintersections.com.au/?p=2673
Lloyd McKenzie (Jul 06 2021 at 16:58):
I don't know we want to 'recommend it', but mentioning it as a "such as" would be useful/appropriate. Its existence is one of the main reasons we opted to not take on that use-case to solve in FHIR directly.
John Moehrke (Jul 06 2021 at 17:59):
please submit a jira ticket
Lloyd McKenzie (Jul 06 2021 at 18:07):
Morten Ernebjerg (Jul 07 2021 at 11:27):
Thanks for the feedback! I think my initial questions was not quite clear (despite the length...) so this went in a different direction than I expected.
First off, I do not want to manage users/user access in any way or link devices to specific patients. I am only interested in account identifiers as a way of identifying "virtual sub-devices" accessible via the API, i.e. I see them as "dumb labels". The API is just the entrance to a data platform where each user has an account. Actual physical devices are always connected to a specific account and access via the API is always to a specific account. Hence, it seemed to me that the platform is really more like a collection of virtual "user-specific aggregation devices" (one per account) and that one should ideally point to such "sub-device" as the source of specific data. For instance, doing so makes it (in certain cases) possible to find out which physical devices collected the data. Hence my question about attaching an account identifier to make the Device instance specific to that "virtual sub-device".
Secondly, I think the term "API" in my question was perhaps a bit misleading. Really, the entity I meant to model is the software platform behind the API which aggregates data from physical devices on a user-specific basis (and does not use FHIR). I was thinking of this as an active producer of data and hence something that would directly add value to e.g. an Observation when linked via Observation.device. E.g. knowing that the data came from this platform allows me to infer information about the raw format, aggregation modes, and precision of the data, and about what types of physical devices it came from (possibly even a specific set of individual devices). That seems quite similar to the information I would gain if a physical device is linked from an Observation. For those reason, it seemed to me that the Endpoint resource or use of Provenance/meta.source was not appropriate since they seemed more geared towards meta-information/information about "passive sources" that do not actually produce the data.
Looking at this, maybe the key question is really this: Are platforms that aggregate data from wearable devices (e.g. the FitBit platform) correctly modelled as Devices (or multiple device, cf. the first point)? Or should one only fill Observation.device if you can refer to the actual, physical device that collected the data?
John Moehrke (Jul 07 2021 at 12:06):
you might want to address this to the #devices stream. There is efforts in this space jointly by the HL7 Devices workgroup and the IHE Devices Domain. I am not deep in that group, so don;t have the answers.
Lloyd McKenzie (Jul 07 2021 at 14:14):
I would say that the software is a device. A user account is not.
Last updated: Apr 12 2022 at 19:14 UTC
