FHIR Chat · CapabilityStatement $export operation · bulk data

Stream: bulk data

Topic: CapabilityStatement $export operation

view this post on Zulip Yunwei Wang (Mar 08 2022 at 16:49):

Bulk Data IG states that

        {
          "type" : "Group",
          "operation" : [
            {
              "extension" : [
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation",
                  "valueCode" : "SHOULD"
                }
              ],
              "name" : "group-export",
              "definition" : "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export",
              "documentation" : "FHIR Operation to obtain a detailed set of FHIR resources of diverse resource types pertaining to all patients in specified [Group](https://www.hl7.org/fhir/group.html).\n\nIf a FHIR server supports Group-level data export, it SHOULD support reading and searching for `Group` resource. This enables clients to discover available groups based on stable characteristics such as `Group.identifier`.\n\nThe [Patient Compartment](https://www.hl7.org/fhir/compartmentdefinition-patient.html) SHOULD be used as a point of reference for recommended resources to be returned and, where applicable, Patient resources SHOULD be returned. Other resources outside of the patient compartment that are helpful in interpreting the patient data (such as Organization and Practitioner) MAY also be returned."
            }
          ]
        },

ONC (g)(10) test procedure requires server implementation support Multi-Patient export so Inferno has a validation test verify that Server declare its support of "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export" in it's CapabilityStatement.
We received a question from an implementer recently that they profiled OperationDefinition of group-export to indicate that their server supports only subset of the input parameters defined in Bulk IG's group-export. They put their own operation definition in server's CS, like

              "name" : "group-export",
              "definition" : "http://myserver/OperationDefinition/group-export",

where http://myserver/OperationDefinition/group-export is a constrained OperationDefinition of http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export
This sounds good but fails Inferno test since Inferno expects the Bulk IG's group-export url.
Here are some questions
1) if server declares "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export" in its CS, does that mean it supports all parameters declared in that OD?
2) how could a server indicate that it supports a constrained group-export operation?
a) using a same name 'group-export' but with different definition url?
b) using a different name 'my-group-export' and with different url?
c) list both 'group-export' and 'my-group-export' side by side (like resource.supportedProfile)
3) how does a client know a server support group-export definition?
a) looking the name 'group-definition'
b) get the OperationDefinition and verify it is either Bulk IG's group-export or descendent of Bulk IG's group-export
4) Should we consider add operation.supportedOperation [0..*] to CapabilityStatement?

view this post on Zulip Josh Mandel (Mar 09 2022 at 13:53):

Can you include a link to the source for the first snippet you embedded (with the SHOULD extension)?

view this post on Zulip Josh Mandel (Mar 09 2022 at 13:54):

  1. http://hl7.org/fhir/uv/bulkdata/STU2/export.html#query-parameters documents which parameters a server is allowed to ignore.

view this post on Zulip Josh Mandel (Mar 09 2022 at 14:03):

  1. http://hl7.org/fhir/uv/bulkdata/STU2/index.html#conformance documents what we specific about advertising conformance -- I.e. populating CapabilityStatement.instantiates. The rest falls back to standard FHIR rules, but in practice it sounds like the vendor you're working with actually supports the full group export operation definition (which allows servers to ignore certain parameters but not others).

(If I wanted to advertise support for a constrained profile I'd advertise just that constrained profile, and populate OperationDefinition.base and host it at $export because -- let's face it -- clients are going to hardcode this path.)

view this post on Zulip Josh Mandel (Mar 09 2022 at 14:06):

  1. see (1) above plus core FHIR spec for ways to advertise
  2. I think core FHIR spec already provides a dizzying array of ways to advertise support for capabilities. If you think something new would help, do you want to write up a proposal for FHIR- I (and especially provide an example showing what you could communicate with this new mechanism that was difficult to communicate with a standard mechanisms)?

view this post on Zulip Yunwei Wang (Mar 09 2022 at 16:47):

Thanks @Josh Mandel Most of the question actually belongs to general FHIR discussion. I will move the discussion to implementer thread.
The quote is from CapabilityStatement in Bulk IG: https://hl7.org/fhir/uv/bulkdata/CapabilityStatement-bulk-data.json.html
I am always confused by the CapabilityStatement with "requirement" kind.
Since Bulk IG states that requirement CS (as above), shall server implementation declare the same name/definition in its instance kind CS?

view this post on Zulip Josh Mandel (Mar 09 2022 at 16:58):

I have no official answer on this. My personal perspective is:

  • servers need to include the instantiates field in their CapabilityStatement, per https://hl7.org/fhir/uv/bulkdata/index.html#conformance -- this is how clients learn "this server does bulk export"

  • servers should host a spec-compliant operation for at least one of:

    • /$export
    • /Patient/$export
    • /Group/:id/$export

Other modeling of "how do I advertise the details of what I do" is outside the scope of Bulk Data; can take this up in FHIR-I.

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -