Stream: inferno
Topic: BDE-02: Bulk Data Server declares support for Group export
Sagar Sarvankar (Nov 04 2021 at 14:08):
This is regarding "name": "group-export" in capabilitystatement. There is an issue raised in HL7 jira that this should be "name": "export", please see thread https://chat.fhir.org/#narrow/stream/179166-implementers/topic/CapStmnt.2Erest.2Eoperation.2Ename.20v.20OpDef.2Ecode . Here there are two issues mentioned which are open with HL7. Any thoughts on this issue and to consider the same in BDE-02?
Yunwei Wang (Nov 04 2021 at 15:18):
Inferno BDE-02 checks operation.definition not operation.name. The definition url shall be "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export"
Sagar Sarvankar (Nov 04 2021 at 15:29):
Thanks Yunwei for a quick response. The existing definition URL we have is "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export|1.0.1" Does it have to be exact "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export"?
Yunwei Wang (Nov 04 2021 at 15:42):
Yes. Inferno checks exact url match. Would you mind to raise a github issue here?
Sagar Sarvankar (Nov 04 2021 at 16:14):
Yes, I will go ahead and create an issue there. But does it mean that "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export|1.0.1" is acceptable and I should mention that in the issue?
Yunwei Wang (Nov 04 2021 at 16:35):
According to the definition of FHIR canonical data type, it should be. Inferno does not handle that pattern now.
Sagar Sarvankar (Nov 04 2021 at 16:38):
Ok, I will create an issue on this. Until the time this issue is open, and during this time we plan to go for Inferno certification, BDE-02 be considered as a pass?
Yunwei Wang (Nov 04 2021 at 17:07):
No :(
You have to use the url without version to pass BDE-02.
Sagar Sarvankar (Nov 05 2021 at 03:09):
Ok, thank you Yunwei for your support.
Sagar Sarvankar (Nov 05 2021 at 13:08):
Hello Yunwei,
I have created an issue (https://github.com/onc-healthit/inferno-program/issues/390) on this. Please review and also let me know who should be the assignee for this.
Thank you.
Sagar Sarvankar (Nov 08 2021 at 05:55):
Hello Yunwei,
Did you get a chance to review the issue (https://github.com/onc-healthit/inferno-program/issues/390)? Please let me know if you need more information.
Also, please assign the same to the concerned person.
Thanks,
Sagar
Yunwei Wang (Nov 08 2021 at 14:21):
@Sagar Sarvankar We are focusing on releasing Inferno Program v1.8 and we will try to resolve this issue asap.
Sagar Sarvankar (Nov 09 2021 at 04:14):
Yes. Thank you @Yunwei Wang
Michelle Vondercrone (Jan 24 2022 at 16:40):
I will be running this test soon, so reading over this issue. Are we saying that the version at the end of the URL will now be required to have BDE-02 pass?
Yunwei Wang (Jan 24 2022 at 17:44):
It is optional. Inferno accept either url or url|version format for canonical url.
Madhur Rajendran (Mar 07 2022 at 15:05):
Is there a reason the url has to be that specific one? We're implementing the export operation, but we're planning on using our own Operation Definition to advertise exactly what our server supports. As far as I can tell, this isn't disallowed by the IG.
Yunwei Wang (Mar 07 2022 at 15:29):
resource.operation is [0..*]. You are free to add your own OperationDefinition url in addition to the required base definition.
Robert Scanlon (Mar 07 2022 at 17:51):
@Madhur Rajendran so you do not support all optional parameters defined in the base bulk data $export definition (e.g. _type), and would like to make that clear by publishing your own OperationDefinition that clients can use to determine the subset you have implemented?
Madhur Rajendran (Mar 07 2022 at 23:01):
@Yunwei Wang the operation would be the same, we'd just be implementing a subset. I think it might be confusing to have the same operation listed twice.
@Robert Scanlon that is correct. Our OperationDefinition would link the official one as the base.
https://www.hl7.org/fhir/operationdefinition-definitions.html#OperationDefinition.base
If the test requires the specific url, it would imply that the server fully supports the guide, which ours doesn't. I think the link to the official OperationDefinition from ours should be valid for the test, as we do advertise that we're supporting that specific operation, but just a subset instead of the full thing.
Madhur Rajendran (Mar 11 2022 at 14:18):
Just wanted to bump this. Are there any thoughts about this? I believe my scenario is still valid according to the FHIR spec, and I don't want my server to end up failing this test because of it.
Yunwei Wang (Mar 11 2022 at 14:52):
What is the name you put in CS?
Madhur Rajendran (Mar 11 2022 at 15:28):
we called it 'group-export'
Robert Scanlon (Mar 11 2022 at 17:28):
If the test requires the specific url, it would imply that the server fully supports the guide, which ours doesn't. I think the link to the official OperationDefinition from ours should be valid for the test, as we do advertise that we're supporting that specific operation, but just a subset instead of the full thing.
This looks right to me... Are you planning on hosting your definition somewhere that clients could access it? Technically, I'm not sure if you have to though.
Robert Scanlon (Mar 11 2022 at 17:37):
Definitely do not want to prevent anyone from doing the correct thing, even if it might be a little more work for clients to determine support for that operation (they would have to get your OperationDefinition to know that it is constrained version of the bulk group export operation, and not an unrelated operation, correct?) In practice though, I doubt this would be a run-time kind of thing that clients check anyhow. A lot of other precoordination needs to happen.
Madhur Rajendran (Mar 14 2022 at 14:52):
We are hosting it at an accessible location, clients should be able to navigate to it through the url in our Capability Statement.
And that is true that they'll have to read the OperationDefinition to see that it's constrained from the bulk export definition, although we might utilize operation.documentation to have it documented on the CapabilityStatement as well.
Josh Mandel (Mar 14 2022 at 15:55):
Can you clarify what specifically you mean by implementing a "subset"?
(@Dan Gottlieb fysa)
Madhur Rajendran (Mar 14 2022 at 18:30):
we're not going to be supporting all the optional parameters of the operation in our implementation. Our group export OperationDefinition will only include the parameters we support. When our implementation is able to support any additional parameters, we can update our OperationDefinition to reflect that.
Josh Mandel (Mar 14 2022 at 19:07):
You can ignore the optional parameters and still "support" them; you don't need a special operationdefinition to describe that behavior. In general I'd recommend hosing a compliant operation at ../$export (you can host your own OperationDefinition or not).
Madhur Rajendran (Mar 15 2022 at 14:52):
We're still using Group/:id/$export as the path for our operation. (That was a bug in my CS, using the value from OperationDefinition.id, instead of OperationDefinition.code, I'll get that updated.)
Robert Scanlon (Mar 15 2022 at 20:56):
Is this question resolved then, without needing to alter our tests? It seems like @Josh Mandel is stating that you shouldn't create your OperationDefinition in this case. And in looking at the documentation for the standard group-export definition, it states how servers should respond if they do not support the optional parameters, which isn't quite the same thing but at least ensures consistent behavior if a parameter isn't supported by a server (e.g. "A server that is unable to support _type SHOULD return an error and FHIR OperationOutcome resource so the client can re-submit a request omitting the _type parameter."). You could still create your own constrained OperationOutcome it if you want, but then have the server respond to that operation somewhere other than Group/:id/$export, and leave Group/:id/$export for the operation that points to the standard definition. Did I get that right?
Josh Mandel (Mar 15 2022 at 21:01):
Formally, you can host any operations at any mount points you choose -- including operations derived from others, operations that just look a lot like others without any formal derivation, and totally independent operations).
Practically speaking though, I expect that clients are not going to be very sophisticated and will just call dollar sign export, so it's pretty important to just make that work. From this practical perspective it doesn't much matter what operation definition you reference, as long as the behavior matches what clients are trying to exercise.
Madhur Rajendran (Mar 16 2022 at 14:13):
I guess I haven't been fully transparent about what our OperationDefinition entails (I didn't want to focus on a particular server's implementation, but rather what is possible). We're planning on supporting a subset of the optional parameters, but we're also planning on supporting some additional parameters from a more recent version of the Bulk IG as well. In this case, our Operation doesn't fully correspond to any particular version of the IG.
The flexibility of having our own OperationDefinition is invaluable to us, since we'll be publishing the exact capability of our server, while also ensuring that we can advertise that the Operation is derived from the IG. Even if clients don't call into the OperationDefinition, we'd prefer it to be as accurate as possible.
Madhur Rajendran (Mar 16 2022 at 14:13):
I guess I haven't been fully transparent about what our OperationDefinition entails (I didn't want to focus on a particular server's implementation, but rather what is possible). We're planning on supporting a subset of the optional parameters, but we're also planning on supporting some additional parameters from a more recent version of the Bulk IG as well. In this case, our Operation doesn't fully correspond to any particular version of the IG.
The flexibility of having our own OperationDefinition is invaluable to us, since we'll be publishing the exact capability of our server, while also ensuring that we can advertise that the Operation is derived from the IG. Even if clients don't call into the OperationDefinition, we'd prefer it to be as accurate as possible.
Madhur Rajendran (Mar 16 2022 at 14:19):
As far as the test goes, if it's supposed to be testing that the Server supports a Group Export operation that is compliant with the IG, then an OperationDefinition with the OperationDefinition.base link to the standard group-export definition should also be valid, right?
The way the test currently is implemented, it seems like it's testing that the server must only support the standard group-export operation specifically.
Madhur Rajendran (Mar 17 2022 at 14:17):
Shall I raise an issue in the github repo?
Yunwei Wang (Mar 17 2022 at 16:01):
Yes please.
Last updated: Apr 12 2022 at 19:14 UTC
