Stream: Orders and Observation WG
Topic: Modeling health apps in FHIR
Tim Blake (Nov 27 2019 at 05:10):
Not sure which stream is best to post this to, but...
Has anybody got any experience of modeling data about health apps in FHIR?
I'm the creator of the Digital Health Guide (www.digitalhealthguide.com.au), a tool for clinicians which allows the review and rating of mobile health apps (and web based digital solutions), as well as locating clinical evidence for apps, and prescribing.
As part of our work we are developing a FHIR-based API to share data from our knowledge base with 3rd parties. We're thinking about profiling Device as the fundamental unit of our logical model, although this will require fairly significant changes. Keen to understand whether anyone else has done work in this space that we could leverage / collaborate on?
Grahame Grieve (Nov 27 2019 at 05:11):
what kind of significant changes?
Grahame Grieve (Nov 27 2019 at 05:11):
generally, there's bubbling discussion about the breadth of the device resource... it's very wide. Are applications really devices? I think ... there's a kind/instance problem here
Grahame Grieve (Nov 27 2019 at 05:13):
are algorithms devices?
Tim Blake (Nov 27 2019 at 05:14):
They can be. They aren't always. I agree that Device gets complicated if you start modeling software...
As it currently stands, Device is very focused on physical devices.
Tim Blake (Nov 27 2019 at 05:20):
There could be a case for a new resource, but I assume that case isn't easily made.
Lloyd McKenzie (Nov 27 2019 at 08:12):
These days, physical devices and software are often highly integrated - and the latter can change while the physical structure remains unchanged.
Tim Blake (Nov 27 2019 at 10:15):
Agree @Lloyd McKenzie . So is that a case for an updated or profiled Device resource, or for a new resource?
Grahame Grieve (Nov 27 2019 at 12:25):
I personally think that we've got the resources wrong here. Device is doing too much, and we shouldn't call software | applications | algorithms devices - though they are often packaged and delivered on | using devices
John Moehrke (Nov 27 2019 at 13:58):
I agree that software, running as a set of cloud services, is really hard to view as a Device. I do like the simplicity of defining all Actors that are not human are Device. To separate software from hardware seems good, but there is so much grey in the middle.
Eric Haas (Nov 27 2019 at 18:47):
@John Rhoads ?
Jose Costa Teixeira (Nov 27 2019 at 20:21):
I can't find a clear boundary between device with software running on it and software running on a device
Jose Costa Teixeira (Nov 27 2019 at 20:27):
“Software as a Medical Device” is defined as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."
Jose Costa Teixeira (Nov 27 2019 at 20:33):
@Grahame Grieve there is a kind/instance issue, both on hardware and on software.
We are looking at prescribing apps (kind) but we will deliver and install apps on mobiles (instances).
Ideas for how we should address software/apps/algorithms? New resource resource for "software" that piggybacks on Device?
Jose Costa Teixeira (Nov 27 2019 at 20:35):
I personally see that device is doing a lot and we need to consider how big that space can get.
OTOH, I do like the notion of having Device as supporting both HW devices and SW on devices
Richard Townley-O'Neill (Nov 28 2019 at 00:01):
How about a device (physical object) resource that references a software (artificial agent) resource?
Both can be a kind or an instance. A kind of device has a model number, but not a serial number. A kind of software has a release number, but does not include configuration details.
Jose Costa Teixeira (Nov 28 2019 at 00:04):
is that the same as having a new resource for "software" that piggybacks on (hardware) Device?
Jose Costa Teixeira (Nov 28 2019 at 00:05):
as in, whenever we want to express a combination, we attach the software resource on top of the hardware resource
Jose Costa Teixeira (Nov 28 2019 at 00:06):
A kind of device has a model number, but not a serial number.
this is what we have with device/deviceDefinition
Jose Costa Teixeira (Nov 28 2019 at 00:07):
A kind of software has a release number, but does not include configuration details.
To me, an instance of software means "my installed app". Kind is "the one in the app store"
Jose Costa Teixeira (Nov 28 2019 at 00:08):
which would link to which? HW to SW? or SW to HW?
Richard Townley-O'Neill (Nov 28 2019 at 00:08):
I think HW links to SW.
Jose Costa Teixeira (Nov 28 2019 at 00:09):
(I'm entertaining the option of splitting HW and SW, but I'm not sure how hairy this can get or what are benefits)
Richard Townley-O'Neill (Nov 28 2019 at 00:09):
How often do we want to send SW without HW?
Jose Costa Teixeira (Nov 28 2019 at 00:09):
App store - SW without HW
Richard Townley-O'Neill (Nov 28 2019 at 00:10):
The split allows simple HW to be managed without considering SW.
Jose Costa Teixeira (Nov 28 2019 at 00:10):
prescribing an app - SW without HW
Richard Townley-O'Neill (Nov 28 2019 at 00:10):
In that case only SW is of interest. No need to mention HW at all.
Jose Costa Teixeira (Nov 28 2019 at 00:10):
if we have one resource, no splitting, we can also manage HW without SW - we just have a lot of optionality...
Richard Townley-O'Neill (Nov 28 2019 at 00:11):
HW may be mature before SW is.
Richard Townley-O'Neill (Nov 28 2019 at 00:12):
Condition and procedure are separate, despite being connected.
Jose Costa Teixeira (Nov 28 2019 at 00:12):
i was thinking that SW links to HW , because that would come first, right? (Maybe it's in my heart - I always preferred hardware..)
Richard Townley-O'Neill (Nov 28 2019 at 00:13):
Yes. HW first, then SW.
Richard Townley-O'Neill (Nov 28 2019 at 00:13):
My mistake earlier.
Richard Townley-O'Neill (Nov 28 2019 at 00:13):
So SW, the later thing, points to HW, the earlier thing.
Jose Costa Teixeira (Nov 28 2019 at 00:15):
I will see how this evolves. My personal (lazy?) reasoning is that there is a gray zone between HW, FW, SW, and because of that, I would prefer one resource that can express any shade in there, rather than having two resources. But I will be exploring this tomorrow.
Jose Costa Teixeira (Nov 28 2019 at 00:15):
thanks for input so far
Tim Blake (Nov 28 2019 at 00:23):
Remember that the original requirement stated above is to model software without hardware. The software I need to model can sometimes include hardware, but usually doesn't.
Tim Blake (Nov 28 2019 at 00:24):
As it stands, Device is a very clumsy way to model software and I need to profile the hell out of it to get it into a usable form.
Richard Townley-O'Neill (Nov 28 2019 at 00:24):
I guess for R4 it is Device.
Tim Blake (Nov 28 2019 at 00:24):
Frankly I'd be better off starting from a new resource, and the only reason to stay with Device was it seems to be the closest thing to the requirements we have at the moment
Richard Townley-O'Neill (Nov 28 2019 at 00:25):
You could make a profile of Device called software.
Richard Townley-O'Neill (Nov 28 2019 at 00:25):
:P
Tim Blake (Nov 28 2019 at 00:25):
I have
Tim Blake (Nov 28 2019 at 00:26):
I might as well have profiled Patient
Lloyd McKenzie (Nov 28 2019 at 00:51):
One reason to stick with Device in R4 is that's what's referenced when we talk about "responsible application"
Tim Blake (Nov 28 2019 at 00:55):
Not sure what that is. Can you please explain?
Lloyd McKenzie (Nov 28 2019 at 01:17):
We list Device as author/performer all over the place
Grahame Grieve (Nov 28 2019 at 02:06):
I don't think Tim deals in attribution. but I think Tim should explain in detail what his attributes are
Tim Blake (Nov 28 2019 at 03:10):
Some very rough thoughts...
dhg.png
Mikael Rinnetmäki (Nov 28 2019 at 08:31):
To add some insight, the FDA now looks at three independent parts in automated insulin delivery:
1) the continuous glucose monitor (hardware with software)
2) the insulin pump (hardware with software)
3) the controller algorithm (pure software, with perhaps some information on which hardware devices it can run on).
See https://www.fda.gov/news-events/press-announcements/fda-authorizes-first-interoperable-insulin-pump-intended-allow-patients-customize-treatment-through
Mikael Rinnetmäki (Nov 28 2019 at 08:31):
Also in regulatory terms, it is clear that a "software only medical device", such as an app, is still a device
Mikael Rinnetmäki (Nov 28 2019 at 08:37):
I like what Tim has started. Not sure why relationships between Device and Condition and between Device and Capability are not many-to-many, though.
Mikael Rinnetmäki (Nov 28 2019 at 08:43):
( see https://www.tidepool.org/blog/what-ace-pump-means-for-tidepool-loop for some more details on automated insulin delivery)
Tim Blake (Dec 03 2019 at 21:12):
So how do we move this conversation forward @Grahame Grieve ? A discussion at the WGM?
Grahame Grieve (Dec 03 2019 at 21:27):
definitely that. but co-chairs... ? @Hans Buitendijk @Lorraine Constable @Rob Hausam
Rob Hausam (Dec 03 2019 at 21:39):
I suspect that a good place to have an initial discussion (assuming we can get the right people there) is the OO on FHIR call (Tuesdays at 2:00 - 3:00 PM Eastern). @Eric Haas?
Jose Costa Teixeira (Dec 03 2019 at 21:50):
This will have a lot of moving parts, so I would favour a discussion in Sydney
Jose Costa Teixeira (Dec 03 2019 at 21:51):
I think the different calls (OO calls on mondays, tuesdays and thursdays) would allow us to identify the topics.
Rob Hausam (Dec 03 2019 at 21:59):
@Jose Costa Teixeira So that sounds like you're in favor of doing both discussion on the calls (one or more) and in Sydney? I would agree with that. Does it make sense to you to start with an OO on FHIR discussion, or do you have a different suggestion?
Jose Costa Teixeira (Dec 03 2019 at 22:00):
It has been hard to get back on schedule for the calls. But we have quite a few of those, at least from OO side.
Jose Costa Teixeira (Dec 03 2019 at 22:01):
so yes, we should discuss on all the calls (next week OO on FHIR call as well) and in Sydney.
Hans Buitendijk (Dec 03 2019 at 22:03):
Could have an in-person at WGM to discuss this. Not convinced this is an OO on FHIR topic, rather a Healthcare Product topic given that we discuss anything device (lowercase) related there. The Monday 3-4pm ET call could work for some, but not necessarily all.
When the consideration is rating Apps, DeviceDefinition seems to be the better choice to start IF we want to consider software a type of device. I would not be opposed to pursuing a separate software resource, but the question is what device types would justify splitting into separate resources rather than profiling the Device and DeviceDefinition as appropriate? What additional or less data would we need?
Jose Costa Teixeira (Dec 03 2019 at 22:04):
I think the calls can help us prepare but this is one elephant that is hard to make carpaccio from...
Jose Costa Teixeira (Dec 03 2019 at 22:04):
here are some of the adjacent topics in a quickly drafted brain map:
Jose Costa Teixeira (Dec 03 2019 at 22:04):
Jose Costa Teixeira (Dec 03 2019 at 22:06):
(we can recenter this on Apps, or on Product, or on SupplyDelivery, but all these roads will still cross, and we better make lasagna, not spaghetti)
Rob Hausam (Dec 03 2019 at 22:06):
If you prefer the Healthcare Product call I wouldn't object - I'll have to join.
Jose Costa Teixeira (Dec 03 2019 at 22:07):
in other words, I would definitely explore separate discussions and analysis, but eventually it should all be synthesized into one design (one or several resources)
Jose Costa Teixeira (Dec 03 2019 at 22:07):
+1 for Product call. I can also join OO on FHIR to see if there is any crumbs we need to pick
Last updated: Apr 12 2022 at 19:14 UTC
