-
Type:
Change Request
-
Resolution: Persuasive with Modification
-
Priority:
Medium
-
FHIR Core (FHIR)
-
DSTU1 [deprecated]
-
FHIR Infrastructure
-
OperationDefinition
OperationOutcome -
6.22.15
-
-
James Agnew / Grahame Grieve: 4-0-0
-
Clarification
-
Non-substantive
-
DSTU1 [deprecated]
Comments
I'd like some clarity on the criteria for defining operations (beyond the restful http set). It seems that the reason for doing so would be to support asynchronous (stateful) functionality. This is
listed as one reason, but it's not clear whether there might be others. For instance, expanding a value set seems like an operation, intuitively, but I'd argue
that an expansion is just another resource. The fact that it's generated dynamically doesn't really enter into it. Ditto for code validation. If these resources were defined, there would be no need for these operations, at least at the base specification.
Grahame's Comments
The essence of an operation is that the server is making some decision; the content returned depends on factors under the control of the server. In the case of expand, the server can return an existing resource, or create a new one it does not store. Because expansion is an operation, there is no expectation that expansions are searchable, for instance. ANd I think that the fact it is generated dynamically is relevant, though it may not be final. It's true that we could also define a resoruce for validation request/response and use this instead. in fact, that's how the FM resources work, and it's a problem. Need to figure out how to express this
- is voted on by
-
BALLOT-267 Affirmative - Jay Lyle : 2015-Jan-FHIR R1
- Closed