Stream: Covid-19 Response
Topic: Tracking hospital operations
Josh Mandel (Mar 20 2020 at 21:35):
Has anyone designed FHIR profiles for tracking the following?
- Available beds (including ICU beds) per facility
- Supply availability per facility (e.g., masks, respirators, test kits)
I'm seeing a whole bunch of conversations about how to track these things, but I haven't seen concrete profiles or examples yet.
Arien Malec (Mar 21 2020 at 04:39):
@Keith Boone is looking at ICU beds
Nancy Lush (Mar 23 2020 at 14:43):
The following site is broader than what you are suggesting, but I think a good approach and could meet those needs: https://hub.bio.org/
Josh Mandel (Mar 23 2020 at 14:59):
Keith let me know that he is going to be publishing a draft guide this morning!
Jason Walonoski (Mar 23 2020 at 16:56):
I'm considering SupplyRequest to model disposable use of gloves, masks, etc.
Jose Costa Teixeira (Mar 23 2020 at 17:03):
supplyrequest is, well, a request, so a planned use, not an actual use
Jose Costa Teixeira (Mar 23 2020 at 17:04):
if you'd want to use somethign to say "we spent these gloves" and given that we do not have a "ProductConsumption" resource, you could better tweak SupplyDelivery for that
Josh Mandel (Mar 23 2020 at 18:50):
@Keith Boone will you let us know here when your IG is up at https://build.fhir.org?
Keith Boone (Mar 23 2020 at 20:22):
Right now it is here https://audaciousinquiry.github.io/saner-ig/, but will be linking to build.fhir.org shortly.
Keith Boone (Mar 23 2020 at 20:22):
I have some minor tweaks to my tooling before I can automate all the stuff.
Jose Costa Teixeira (Mar 23 2020 at 20:36):
the IG looks great.
Content-wise, I believe Group is intended to be a group of subjects that will be acted upon, so I'd have preferred to use List for this.
Josh Mandel (Mar 23 2020 at 20:40):
I think the practical challenge with List is that if you want to just provide counts, there's no place to do it (vs Group.quantity, which lets you supply a total without enumerating members). @Keith Boone were there other considerations?
Jose Costa Teixeira (Mar 23 2020 at 20:43):
yes, I am just recalling (I think) the discussions about the intended use of Group. If the Group is the entity that is being acted upon (also judging from the places where Group is used like .subject in several resources)
Jose Costa Teixeira (Mar 23 2020 at 20:44):
I don't think we have any resource that is ideal for this concept, anyway
Josh Mandel (Mar 23 2020 at 20:45):
@Grahame Grieve @Lloyd McKenzie Is there a formally endorsed way to refer to a FHIR Element path in a Coding? In Keith's draft IG I see values like:
"coding": {
"system": "http://hl7.org/fhir/location-definitions.html",
"code": "Location.status"
}
Using the HTML page in a system seems slightly off, but I have to admit I'm not sure if we've defined any official alternative.
Josh Mandel (Mar 23 2020 at 20:46):
Also @Keith Boone I'd be happy to contribute examples to the IG (I don't see any yet -- let me know if I'm missing anything).
Jose Costa Teixeira (Mar 23 2020 at 20:46):
what about the Expression data type?
Josh Mandel (Mar 23 2020 at 20:47):
For fields like feature and location @Keith Boone I was thinking we might just use a valueReference instead of repeating all the Location fields within Group characteristics. Before seeing your guide I wrote up an example at https://gist.github.com/jmandel/41f47088085cf4633506b43438925389#file-tracking-examples-json-L66-L77 (you can ignore all but the highlighted snippet; other details still need to be aligned to your IG) -- curious if you considered this?
Josh Mandel (Mar 23 2020 at 20:48):
Jose Costa Teixeira: what about the Expression data type?
What about it?
Jose Costa Teixeira (Mar 23 2020 at 20:48):
To refer to the element path
Josh Mandel (Mar 23 2020 at 20:49):
@Jose Costa Teixeira I mean to say: Group.characteristic.code is a CodeableConcept -- so the question is what's the preferred way to represent a FHIR element path as a Coding. Can you share an example of how you'd use an Expression for this (??inside a Coding?)
Jose Costa Teixeira (Mar 23 2020 at 20:52):
ah sorry, I was thinking that this was something we could change the data type.
Keith Boone (Mar 23 2020 at 20:57):
Josh Mandel said:
I think the practical challenge with List is that if you want to just provide counts, there's no place to do it (vs Group.quantity, which lets you supply a total without enumerating members). Keith Boone were there other considerations?
Two considerations: 1) as @Josh Mandel mentions, counts. 2) ability to define and query by defined characteristics, which Group has but List does not.
Keith Boone (Mar 23 2020 at 21:07):
Josh Mandel said:
Also Keith Boone I'd be happy to contribute examples to the IG (I don't see any yet -- let me know if I'm missing anything).
Examples would be helpful, but first we need to get the community all agreed that we are headed in the right direction. I think this is a good start, but then I _might_ have some bias.
Josh Mandel (Mar 23 2020 at 21:10):
I think this is a great start. I'll add some questions etc on Github, and looking forward to connecting tomorrow. I'm working with @Gino Canessa and @Carl Anderson on some sample data now to try things out / develop some opinions :)
Vassil Peytchev (Mar 23 2020 at 21:10):
Did you consider specific operation together with a count extension on List? What is being proposed doesn't exist anyway, so it is unlikely that the barrier to implementation will be higher with an operation. In fact, with an operation you can have an output parameter for count, and another for the List.
Keith Boone (Mar 23 2020 at 21:11):
@Josh Mandel @Grahame Grieve @Lloyd McKenzie I'd prefer to use http://hl7.org/fhir as the coding system for paths, or perhaps http://hl7.org/fhir/R4 (because the paths change by version), perhaps with some additional value if you want to keep it separate from the core FHIR namespace. Frankly, the paths are a vocabulary defined by FHIR itself.
Josh Mandel (Mar 23 2020 at 21:11):
@Vassil Peytchev Getting good search capabilities out of the box is a big win; Group.characteristic has search indexes in place.
Jose Costa Teixeira (Mar 23 2020 at 21:11):
This as a short term solution, sure, that is what we have.
I echoed that Group is a different concept, so in the long term I don't think it is a good choice. The alternative would be extensions.
Vassil Peytchev (Mar 23 2020 at 21:16):
@Josh Mandel Out of which box? Is the assumption that defining a resource means the search capabilities exist for free? If there is no implementation of Group, I doubt that there is much difference between implementing a selection over a set of operation input parameters for the particular purpose, and implementing a Group resource. Given the ad-hoc nature of this, operations should be given a good look.
Jason Walonoski (Mar 23 2020 at 21:26):
Jose Costa Teixeira said:
if you'd want to use somethign to say "we spent these gloves" and given that we do not have a "ProductConsumption" resource, you could better tweak SupplyDelivery for that
The only problem with SupplyDelivery, is that it doesn't have a reason code or reference. e.g. ventilation due to respiratory distress due to COVID19. Although that could be an extension... And another issue with SupplyRequest, is that a Procedure cannot be reason (e.g. ventilation is likely a procedure).
Jose Costa Teixeira (Mar 23 2020 at 21:29):
Jason Walonoski said:
The only problem with SupplyDelivery, is that it doesn't have a reason code or reference. e.g. ventilation due to respiratory distress due to COVID19. Although that could be an extension... And another issue with SupplyRequest, is that a Procedure cannot be reason (e.g. ventilation is likely a procedure).
Ok so this is not only "we used these gloves" but "we used these gloves because we were admitting patients" which is not a supply anymore, right?
Vassil Peytchev (Mar 23 2020 at 21:30):
Having said that, Group already allows Device to be a member, and with Device.type being pretty much everything, Group is very close to being useful as is...
Jose Costa Teixeira (Mar 23 2020 at 21:31):
I prefer to have the immediate needs in this thread, and the "what we can do in the future" in the committers stream.
for the immediate needs, I'm happy to defer to the comments on Keith's approach
Jason Walonoski (Mar 23 2020 at 21:32):
Jose Costa Teixeira said:
Ok so this is not only "we used these gloves" but "we used these gloves because we were admitting patients" which is not a supply anymore, right?
OK. So what is it then? Genuinely curious what the other sane options are.
Jason Walonoski (Mar 23 2020 at 21:33):
Keith Boone said:
Right now it is here https://audaciousinquiry.github.io/saner-ig/, but will be linking to build.fhir.org shortly.
Keith, it looks like the SupportingDevice profile is incorrectly derived from Location.
Jose Costa Teixeira (Mar 23 2020 at 21:34):
today, there are no sane options. This was not considered.
Keith Boone (Mar 23 2020 at 21:40):
Josh Mandel said:
I think this is a great start. I'll add some questions etc on Github, and looking forward to connecting tomorrow. I'm working with Gino Canessa and Carl Anderson on some sample data now to try things out / develop some opinions :)
I'm using FSH for development, so if you can build samples using FSH files, those can easily drop in. JSON and XML will of course work easily, but aren't as easy for real people instead of tech-heads like us to modify.
Josh Mandel (Mar 23 2020 at 21:40):
(For discussion tomorrow, I'm going to explore a flat Location-based approach, too -- want to make sure we understand trade-offs. The obvious downside to a flat list is that we might not know information about individual beds, but over time we expect to have more granular and automated feeds, so representing the data in a granular way up-front can be nice. It allows better use of FHIR search infrastructure, Bundle.count, etc)
Keith Boone (Mar 23 2020 at 21:43):
Group supports definition by intention as well as by enumeration. For public health reporting, they frankly aren't interested in the enumeration of the list, rather, what they can from aggregates classified.
Josh Mandel (Mar 23 2020 at 21:45):
Yes, for sure -- but using Group means storing a bunch of Location semantics into group characteristics, and though FHIR search kind of exists for these, composite search parameters aren't that well supported in real life (e.g., HAPI's server doesn't handle these right)
Josh Mandel (Mar 23 2020 at 21:45):
But I agree, there're many use cases that might only care about counts.
Josh Mandel (Mar 23 2020 at 21:46):
These could be handled by _summary=count queries, though. In other words, clients could request counts without needing to materialize them in a Group.
Keith Boone (Mar 23 2020 at 21:46):
@Josh, that sounds like HAPI's implementation over storage, b/c I KNOW I've used HAPI to pass composites to an implementation I build that DOES do the right thing.
Josh Mandel (Mar 23 2020 at 21:47):
Yeah, it's a db/storag issue rather than a query parsing issue.
Josh Mandel (Mar 23 2020 at 21:47):
(Anyway, to be clear, there's extreme value in not thrashing on design -- so picking something quickly, documenting its warts, and moving on is great.)
Vassil Peytchev (Mar 23 2020 at 21:52):
Summary of initial thoughts (sorry, cannot make it tomorrow):
- Operations allow to define exactly what we are looking for, and what we want back (good for an ad-hoc, urgent implementation)
- Group ->member-device->location makes more sense than Group->member-location (unless the intention is to not use member at all)
Josh Mandel (Mar 23 2020 at 21:54):
Re: operations, my concern is that they require custom coding. For something urgent, being able to use off-the-shelf FHIR servers is a big win.
Josh Mandel (Mar 23 2020 at 21:54):
(I agree that the semantics of Operations are powerful / well-suited.)
Vassil Peytchev (Mar 23 2020 at 21:55):
Good point, but not universal :grinning:
Josh Mandel (Mar 23 2020 at 21:55):
And on (2), currently a group can't have a "member location" so it's good you find that "member device" makes more sense ;)
Josh Mandel (Mar 23 2020 at 21:56):
We're prototyping something with flat Locations to see how this works, too. @Vassil Peytchev do you have a perspective on this?
Vassil Peytchev (Mar 23 2020 at 22:00):
Not currently. I understand the initial thought (beds are locations in ADT feeds), but I don't know if using Location makes things easier. At first glance using Device is more versatile.
Josh Mandel (Mar 23 2020 at 22:02):
(So, there's the "Use Group for counts, vs just query resources for counts" discussion, and the "Use Locations, vs use Devices" discussion. I think you're commenting on the latter, but I also want to get your take on the former if you have one.)
Vassil Peytchev (Mar 23 2020 at 22:05):
Use "something" for counts - Group or an output/input parameter, or something else:
I suspect that explicit counts is better. _summary=count may not be useful for Public Health.
Josh Mandel (Mar 23 2020 at 22:07):
Could imagine defining a public health query operation to provide these answers, given a server with granular data stored inside of it. This might a good/flexible pattern (submit / store granular details, and generate summary reports as needed).
Keith Boone (Mar 23 2020 at 22:22):
Josh Mandel said:
And on (2), currently a group can't have a "member location" so it's good you find that "member device" makes more sense ;)
My thinking on this as I examined location originally was that individual beds weren't what PH wants to know about. That led me to Group. From there it was pretty easy to diagnose that Group didn't support "Location". But then thinking it through: A bed is a device (I used to work for companies that made very specialized beds among other things), and Location is simply an attribute of the device (where it is right now). In fact, for some of this, you have to go through device to get to location, and then attributes of location to determine other devices to get to "This bed supports negative airflow isolation". This isn't a row in a table, it's a report on a view of several tables, which may include devices and locations, which can support certain functions of interest to the "customer" (Public Health). That led me right back to Group and characteristics...
FWIW: Lots of device manufacturers also spend a good bit on Health IT development around helping facilities track those expensive devices, and those systems integrate with the EHR and so I'm back again to "Report to customer what they want to know about Beds" as opposed to report about each an every bed (Location).
Central Monitoring, ICU Management and Bed Management solutions have a place in this, I think.
Vassil Peytchev (Mar 23 2020 at 22:41):
Keith Boone said:
This isn't a row in a table, it's a report on a view of several tables, which may include devices and locations, which can support certain functions of interest to the "customer" (Public Health).
That's what leads me to operation(s)....
Keith Boone (Mar 23 2020 at 22:47):
@Vassil Peytchev If you or I were building it from our infrastructure, Operations is a completely logical place to start (in fact I spent some time thinking about this as an operation on Location). But if someone is trying to build this by gluing together various parts, an off the shelf FHIR server and something that pulls from a bed management component or EHR directly, then they have to write the code to do the operation. Whereas, with group, they can have one component write and update groups, and another public health/hie facing one to support reporting via queries.
Vassil Peytchev (Mar 23 2020 at 23:03):
Keith Boone said:
But if someone is trying to build this by gluing together various parts, an off the shelf FHIR server and something that pulls from a bed management component or EHR directly, then they have to write the code to do the operation.
I think you might be overestimating the difference in effort between the two.
Another very important point is to consider what is easier for the customer (Public Health). That should be the deciding factor, and hopefully we can have them involved from the beginning.
Keith Boone (Mar 23 2020 at 23:06):
Josh Mandel said:
For fields like feature and location Keith Boone I was thinking we might just use a valueReference instead of repeating all the Location fields within Group characteristics. Before seeing your guide I wrote up an example at https://gist.github.com/jmandel/41f47088085cf4633506b43438925389#file-tracking-examples-json-L66-L77 (you can ignore all but the highlighted snippet; other details still need to be aligned to your IG) -- curious if you considered this?
@Josh Mandel Actual, Location is valueReference already if you look at the differential here: https://audaciousinquiry.github.io/saner-ig/StructureDefinition-saner-bed-group.html
For Feature, I have a code set, but realized I hadn't plugged it in. For Bed, it just covers Isoloation, with three values: NEGISO, OTHISO, NONISO to allow reporting of beds that support Isolation.
Lloyd McKenzie (Mar 24 2020 at 01:49):
Sorry for taking so long to respond - long day of calls, then home stuff. Based on this solution for pointing to elements in Questionnaire my leaning might be to go with "http://hl7.org/fhir/R4/StructureDefinition" as the code system. But I'm not sure the StructureDefinition is critical.
Lloyd McKenzie (Mar 24 2020 at 01:51):
I'm fine with whatever is fastest to get up and running here, but I would like a disclaimer somewhere noting that's what we've done and that some of the resources are being abused to go beyond their intended functions - I'd rather not have people using Group this way 2 years from now
Josh Mandel (Mar 24 2020 at 02:08):
Thanks. I think system: http://hl7.org/fhir/StructureDefinition/Location , code: Location.status makes sense / follows the existing pattern.
Josh Mandel (Mar 24 2020 at 02:09):
(And at least the URL resolves / redirects properly, for now anyway ;-))
Keith Boone (Mar 24 2020 at 02:31):
I'm happy with @Lloyd McKenzie's suggestion, like it even
Josh Mandel (Mar 24 2020 at 02:57):
To be clear, is Lloyd suggesting "http://hl7.org/fhir/StructureDefinition/Location" or "http://hl7.org/fhir/StructureDefinition" as the system? Text suggests the latter, but his example suggests the former.
Josh Mandel (Mar 24 2020 at 02:58):
"http://hl7.org/fhir/StructureDefinition/Location" is the one that makes sense to me.
Lloyd McKenzie (Mar 24 2020 at 03:00):
An element is typically expressed as Location.identifier, so including Location in the system is somewhat redundant.
Lloyd McKenzie (Mar 24 2020 at 03:01):
(We should use the element paths as the element identifier - given that that's what we do everywhere else)
Josh Mandel (Mar 24 2020 at 03:06):
OK -- I'm having trouble seeing how this aligns with the example of
http://hl7.org/fhir/StructureDefinition/Observation#Observation.comment
I would have thought the part before # corresponded to a system, and the part after corresponded to a code.
Josh Mandel (Mar 24 2020 at 03:07):
The other obvious advantage is that the system URL points to something relevant (i.e., http://hl7.org/fhir/StructureDefinition/Location has relevant content, http://hl7.org/fhir/StructureDefinition not so much)
Lloyd McKenzie (Mar 24 2020 at 03:16):
My recommendation is: {"system":"http://hl7.org/fhir/R4/StructureDefinition", "code":"Observation.comment"}
Lloyd McKenzie (Mar 24 2020 at 03:17):
The URL resolution bit is true. Whether that justifies the redundancy, I don't know.
Josh Mandel (Mar 24 2020 at 03:18):
Can you clarify though how this aligns with the page you linked to?
Josh Mandel (Mar 24 2020 at 03:18):
I'm just missing where http://build.fhir.org/questionnaire.html#definition makes this recommendation, and it seems (to me) to say the other thing.
Keith Boone (Mar 24 2020 at 03:20):
What we need is something like http://hl7.org/fhir/valueset-defined-types.html for fields. What I used at least got people to a URL that resolved to something. I think we could also eventually get to http://hl7.org/fhir/valueset-defined-elements.html, which might help.
Lloyd McKenzie (Mar 24 2020 at 03:22):
@Josh Mandel Looking at it more carefully, you're correct. The redundancy is there to allow pointing to profiles and logical models
Keith Boone (Mar 24 2020 at 03:23):
Yup, it just so happens that all FHIR StructureDefinition resources have that Redundancy, but extensions and profiles don't. I can live with the redundancy.
Let's stick with that precedent unless/until it becomes changed. Better to have one way to do this.
Last updated: Apr 12 2022 at 19:14 UTC
