Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-26390

FHIR#26368 resolution does not match actual issue, needs further discussion

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: High High
    • FHIR Core (FHIR)
    • R5
    • FHIR Infrastructure
    • Parameters
    • Hide

      Change the current definition "This resource is a non-persisted resource used to pass information into and back from an operation. It has no other use, and there is no RESTful endpoint associated with it." to:

      "This resource is used to pass information into and back from an operation (whether invoked directly from REST or within a messaging environment).  It is not persisted or allowed to be referenced by other resources except as described below."

      In the usage notes for Parameters include the following section:

       

      Because Parameters does not reflect a persistent healthcare-related entity, but rather just a collection of data passed into or out of an operation, there is generally no need to have a RESTful endpoint at which such instances can be created, updated, queried, etc.  However, there are a few limited cases where this can make sense:

      • Parameters instances can be stored to record inbound and/or outbound information in support of an [AuditEvent] instance
      • Parameters instances might be persisted either on their own or as part of a Bundle to support documentation of examples for an [ImplementationGuide] and/or test data for a TestScript

      Technically, Parameters is a specialization of Resource, and as such, could potentially appear anywhere that 'Resource' is permitted and could be referenced anywhere an element has an unconstrained type of Reference.  For example, they could appear in FHIR documents, as contained resources, referenced by extensions, in elements like Observation.focus, etc.  However, such use is prohibited unless the element containing the Resource or Reference type explicitly indicates that Parameters is permitted.  If there is a requirement to exchange arbitrary collections of data elements, this need should typically be met using [Basic].

      Explicitly adjust language in following places to allow Parameters to be included

      • MessageHeader.focus
      • TestScript.fixture.resource
      • Bundle.entry.resource (note that must be referenced by something else within the Bundle that provides context/meaning)
      • DomainResource.contained (note that must be referenced by a resource that provides context/meaning)
      • AuditEvent.entity.what
      Show
      Change the current definition "This resource is a non-persisted resource used to pass information into and back from an  operation . It has no other use, and there is no RESTful endpoint associated with it." to: "This resource is used to pass information into and back from an  operation  (whether invoked directly from REST or within a messaging environment).  It is not persisted or allowed to be referenced by other resources except as described below." In the usage notes for Parameters include the following section:   Because Parameters does not reflect a persistent healthcare-related entity, but rather just a collection of data passed into or out of an operation, there is generally no need to have a RESTful endpoint at which such instances can be created, updated, queried, etc.  However, there are a few limited cases where this can make sense: Parameters instances can be stored to record inbound and/or outbound information in support of an [AuditEvent] instance Parameters instances might be persisted either on their own or as part of a Bundle to support documentation of examples for an [ImplementationGuide] and/or test data for a TestScript Technically, Parameters is a specialization of Resource, and as such, could potentially appear anywhere that 'Resource' is permitted and could be referenced anywhere an element has an unconstrained type of Reference.  For example, they could appear in FHIR documents, as contained resources, referenced by extensions, in elements like Observation.focus, etc.  However,  such use is prohibited unless the element containing the Resource or Reference type explicitly indicates that Parameters is permitted.  If there is a requirement to exchange arbitrary collections of data elements, this need should typically be met using [Basic] . Explicitly adjust language in following places to allow Parameters to be included MessageHeader.focus TestScript.fixture.resource Bundle.entry.resource (note that must be referenced by something else within the Bundle that provides context/meaning) DomainResource.contained (note that must be referenced by a resource that provides context/meaning) AuditEvent.entity.what
    • Grahame Grieve/Marten Smits: 11-0-0
    • Clarification
    • Non-substantive
    • R5

    Description

      https://jira.hl7.org/browse/FHIR-26368 was created with the intent of providing a use case for adopting the use of Parameters in messaging. The resolution, however, only expands the use of Parameters in a general way, without addressing the original assumption that there is a need to use Parameters in MessageHeader, or how to use Parameters in messaging (As a reference from MessageHeader.focus? As a reference from a new element? As a contained resource?)

      The proposed change in FHIR#26368 is from

      This resource is a non-persisted resource used to pass information into and back from an operation. It has no other use, and there is no RESTful endpoint associated with it.

      to

      This resource is a non-persisted resource primarily used to pass information into and back from an operation. There is no RESTful endpoint associated with it.

      This raises the following issues:

      • it could be argued that the change actually modifies an implicit invariant in that wherever you had Reference(Any) , it was "any resource, except for Parameters". With the change, the invariant is no longer valid.
      • The original text explicitly linked to http://hl7.org/fhir/operations.html as the definition of operation. If messages and subscriptions need to be considered as special cases of operations, then updating the operations.html page to say so will satisfy the perceived need to expand the use of Parameters, without relaxing anything in the Parameters definition. It makes more sense that expanding the use of Parameters needs to follow the specific use case(s) that we agree on, and not introduce general and vague language ("primarily used?") so as to not be helpful.

      Proposed resolution:

      1. Postpone the application of FHIR#26368 until
      • The use case for expanding the use of Parameters is clarified
      • The discussion on the guidance for using messaging and subscription (in particular, determining what is a notification) comes to a point close to consensus, as this may affect the use case for expanding the use of Parameters.
      1. If expanding of the use of Parameters is still necessary, expand it to the particular use cases (e.g. can be used as contained resources in MessageHeader), and not generally to everywhere.

      Attachments

        Activity

          People

            michael_donnelly Michael Donnelly
            vassil Vassil Peytchev
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: