Stream: bulk data
Topic: Group Export
Michelle Vondercrone (May 20 2020 at 12:24):
This may be an obvious question, but looking to resolve a difference of opinion.
The FHIR operation for all data on a group of patients is: GET [fhir base]/Group/[id]/$export.
The brackets around id does NOT mean optional (as it does in HL7), correct? It is just a representation for substitution, correct?
Seems obvious that id is REQUIRED as part of the URL for group export. But, I guess if not valued, it could be interpreted for get all patients.
Please help me clarify.
Vladimir Ignatov (May 20 2020 at 12:39):
That is correct. URLs like https://myfhirserver/Group/abc/$export are valid but https://myfhirserver/Group/$export is not. To get all patients use [fhir base]/Patient/$export.
Michelle Vondercrone (Jul 15 2020 at 13:26):
Looking for opinions @Dan Gottlieb
As part of Group Export, we are allowing configuration on our system for the Group. Configuration will include the definition of the group id and will be associated with a database query to get the list of patients.
So, when the Group Export is initiated with the ID of the group configured in our system, the first step before retrieving the resource data will be to get the list of patients in the group by running the associated query.
In the case of the query returning no patients, this is not really an error, so is it valid to create an informatinoal OperationOutcome and upon status request return Complete with OperationOutcome in the Output?
{
"transactionTime": "[instant]",
"request" : "[base]/Patient/$export?_type=Patient,Observation",
"requiresAccessToken" : true,
"output" : [{
"type" : "OperationOutcome",
"url" : "http://serverpath2/OperationOutcome_file_1.ndjson"
}],
"error" : [ ]
}
Dan Gottlieb (Jul 15 2020 at 14:53):
My inclination would be to use an empty output array to indicate that no data is available for the group, but I'm curious what others folks think?
Josh Mandel (Jul 15 2020 at 15:00):
Agreed Dan -- there's a close analogy to http://build.fhir.org/bundle-definitions.html#Bundle.entry.search.mode
Josh Mandel (Jul 15 2020 at 15:00):
which provides a clear way to indicate whether you are seeing a resource because it matched your search or because it is giving you information about your search.
Josh Mandel (Jul 15 2020 at 15:01):
For the export operation, the closest bucket we have to this is called "error" -- perhaps we should expand the meaning of this field to encompass any operation outcomes that give you information about the result rather than strictly errors.
Yunwei Wang (Jul 15 2020 at 15:03):
I agree. I would expect an empty output array in such situation. (which means the group is empty)
@Josh Mandel I don't quite understand what information server could provide in the "expanded" error array
Nathan Hall (Jul 15 2020 at 15:19):
It's different than a search with query params that returns no results, but I think the idea is the same in that the server::
Shall return 200
May return an OperationOutcome with more information for the client to diagnosis the issue
Josh Mandel (Jul 15 2020 at 15:21):
My goal is just to make sure a client never thinks that the operation outcome is a resource returned by the search. If you put it in the outputs array, that is the implication.
Josh Mandel (Jul 15 2020 at 15:23):
So if we think it's important to return such an OperationOutcome, I'd like to make sure we put it somewhere other than the "outputs" array. Right now the only contender is the "errors" array, which is actually pretty close to what we want (but its scope is a bit too narrow -- today, it's just for information that represents an error, rather than any information that you want to convey alongside your export results).
Michelle Vondercrone (Jul 15 2020 at 15:29):
Thanks for the feedback everyone. We can send an empty array in 'Output' and the informational Operation Outcome in 'Error' (if we an expand the scope of Error), otherwise my only other option is to have the request itself fail (which is not really correct either).
Yunwei Wang (Jul 15 2020 at 15:36):
@Josh Mandel That makes sense. Maybe we should also change the name "errors" to "issues" if we decide to expand that element
Yunwei Wang (Jul 15 2020 at 15:38):
Related question: why errors is required? It is not fun to return an empty array all the time where there is no "error".
And this sentence is interesting: "If no errors occurred, the server SHOULD return an empty array." If errors is required and there is no error, what other options for server rather than returning an empty array. (It is SHOULD which means server MAY do something different.)
Dan Gottlieb (Jul 15 2020 at 16:46):
Yup, agree that it's worth considering renaming the errors field and expanding its scope to include info and warning level OperationOutcomes. What do folks think of the name "issues" that @Yunwei Wang proposed (I like that it aligns with the language used in the OperationOutcome)?
Dan Gottlieb (Jul 15 2020 at 16:49):
Re: the errors array with no errors, I don't remember why we made it a SHOULD rather than a SHALL. It seems like we should either require an empty array or explicitly leave it up to servers to choose, since in the case of a SHOULD, clients will have to handle parsing both possibilities anyway. Thoughts?
Michelle Vondercrone (Jul 15 2020 at 17:11):
I am good with Issue instead of Error. I see Issue used in FHIR R4 OperationOutcome definition:
https://www.hl7.org/fhir/operationoutcome-example-exception.json.html
https://www.hl7.org/fhir/operationoutcome-example-allok.json.html
I wouldn't want to have to write an OperationOutcome though if all ok. Could this be an empty array []?
Michele Mottini (Jul 15 2020 at 17:14):
Changing the name of the property would be a breaking change
Dan Gottlieb (Jul 15 2020 at 17:24):
@Michele Mottini - I was thinking we could phase it by expanding the definition in v1.2 and renaming the field in v2 (didn't express that very well though :)
Dan Gottlieb (Jul 15 2020 at 17:27):
@Michelle Vondercrone Agreed - would definitely want to continue allowing an empty error array (and/or omitting the property entirely, depending on what we decide on the other issue in this thread)
Ritika Jain (Jan 15 2021 at 19:43):
hello, can the groupings be pre-defined by server, for example on age bracket or a postal code etc. Also, where would the group ids be retrieved from, is there a request for that ? or have to be configured in the client ? @Dan Gottlieb @Josh Mandel
Dan Gottlieb (Jan 15 2021 at 20:09):
Yup, the groups are FHIR Group resources (https://www.hl7.org/fhir/group.html) so depending on the server they may be defined elsewhere and exposed through a FHIR interface (eg. patients in a postal code or the roster of patients for a particular plan at a payor) or could be groups of specific patients that a client can save to the server (as is the case in the CMS Data at the Point of Care project at https://dpc.cms.gov/docs#groups-attribution).
Dan Gottlieb (Jan 15 2021 at 20:09):
Based on the IG, servers should support listing and searching for Groups using the FHIR REST API. Of course some servers may omit that interface and rely on ids the client should already be know (eg. plan id numbers for particular payor)
Moin Syed (Jun 23 2021 at 06:51):
I have few questions on group export.
Based on the discussion it is mentioned that the group details could be fetched from FHIR (https://www.hl7.org/fhir/group.html). How do we create the group, who creates it?
In the inferno test (or any certification test), how does it get the group ids to verify? for eg The inferno test tool takes "fhir/Group/1/$export", how does it fetch the group id as 1?
@Dan Gottlieb @Josh Mandel
Michele Mottini (Jun 23 2021 at 13:09):
Groups can be created using normal FHIR POST / PUT interactions, or in some off-band ways specific to each system. The bulk specs do not say anything about that.
Michele Mottini (Jun 23 2021 at 13:10):
Similar for the group id: clients have to know which id to use - they could search groups using normal FHIR searches or some other method like a pre-configured list
Josh Mandel (Jun 23 2021 at 15:32):
Adding to this point, it's entirely possible that an EHR might only support "out of band" Group creation (e.g., register your client and get access to a pre-defined group, or upload a patient list to negotiate a new group through some administrative process, etc).
Yunwei Wang (Jun 24 2021 at 14:49):
Inferno assumes the group to be tested already exists on the server.
Tom Lipcsey (Jul 27 2021 at 17:00):
Hi All,
Great discussion. I just want to clarify the expectation of the Population Query from the EHR Vendor API perspective. The groups are created off a pre-determined cohort list from say an external pop health system.. i.e. All patients over 65 who have not had a covid shot. This list of patient ID's would be used in the creation of the FHIR group for the planned EHR query. There is no expectation for the EHR Vendors API to do that search work, create the group and further manage it correct? I.e. This is a group imported from external system outside the EHR and managed by that outside system.
Last updated: Apr 12 2022 at 19:14 UTC
