Details
-
Change Request
-
Resolution: Persuasive with Modification
-
High
-
FHIR Core (FHIR)
-
R5
-
FHIR Infrastructure
-
Parameters
-
-
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:
- 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.
- 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
Issue Links
- mentioned in
-
Page Loading...