...
The intent of the page is to capture this position as a distillation of the discussion for use in refining the FHIR specification in HL7 processes.
Recommendations
That
- the "excludePostCoordinated" parameter of $expand be changed to "includePostCoordinated" and default to a value of false, and
- any SNOMED CT ValueSet $expand result of SUBSETTED guarantees to include at least all pre-coordinated SNOMED CT content for the version expanded against, and
- libraries of well known post-coordinated codes for code systems (e.g. UCUM and MIME) be defined, centralised and version managed, and included when "includePostCoordinated" is false for these well known cases
...
The problem
When expanding a ValueSet, the current default is to include post-coordinated content (unless the parameter "excludePostCoordinated" is included in the request and set to true). Clarification resulted in determining that, as currently specified, the correct response to such a request is to return all pre-coordinated and all possible post-coordinated concepts matching the ValueSet definition - that is all possible calculable post-coordinated content given the pre-coordinated content in the edition, post-coordinated grammar, and concept model.
This is considered problematic as it is However this is very difficult for servers to calculate (both technically difficult to implement and computationally costly) and rarely what a client is likely to want. Default behaviour with minimum specified parameters should match the common case for clients. Most current server implementations also currently do not calculate and respond with post-coordinated content due to the difficulty and relative lack of utility or client demand, even when the client does not specify "excludePostCoordinated". As a result they incorrectly respond with an expansion based on pre-coordinated content only . The recommended default brings the specification in line with the behaviour exhibited in the servers, and the common misunderstanding of the current specificationwithout declaring it a SUBSETTED response.
Were servers to be updated to implement the specification as it currently stands, it is unlikely that many if any would implement such that they respond with all possible post-coordinated content matching the ValueSet. Therefore most, if not all, servers would return a SUBSETTED response, or "too costly" to common requests. A a request where the client omits "excludePostCoordinated" (currently the most common case).
While a "too costly" response in a this very common case is not useful to the client, the a SUBSETTED response is useful however . However as this would almost always be the case it does not allow the client to understand what may be omitted in the subset and whether it is usable, and may vary per serverdistinguish whether the expansion was generated from a fragment of SNOMED CT pre-coordinated content, or whether it was generated from all the pre-coordinated content but does not include all possible post-coordinated expressions.
All of these issues lead to varied behaviour of servers and a potential lack of portability of client code to different servers, as responses may vary.
The recommendations are made in an attempt to provide a specified behaviour servers can implement and standardise on, and clients can depend upon for interoperability. The recommendations also attempt to have the default behaviour under the specification be the most commonly required behaviour, requiring the fewest implementations to specify additional parameters to modify behaviour.
Changing "excludePostCoordinated" with a default of false, to "includePostCoordinated" with a default value of false allows most server implementations to continue as they are currently doing - respond with pre-coordinated content matching the ValueSet definition in a non-SUBSETTED response. This is also considered the most commonly required case for clients, as most systems cannot handle post-coordination.
...
Recommendations
That an expansion of a ValueSet where excludePostCoordinated is omitted or false is not a SUBSETTED response if it contains
- all matching pre-coordinated content from the version of SNOMED CT it is expanded against
- all the explicitly listed post-coordinated expressions in the ValueSet
That is, a ValueSet expansion result against SNOMED CT only responds with a SUBSETTED response if the response was generated from a fragment/subset of the pre-coordinated content of the SNOMED CT version it was expanded against, and/or post-coordinated expressions explicitly listed in the ValueSet were not included.
Unless the client specifies excludePostCoordinated, it can assume that the response may contain some (but unlikely all) of the post-coordinated expressions that are syntactically and semantically valid given the SNOMED CT pre-coordinated content from the version being expanded, post coordination grammar and the concept model.
An additional, related, recommendation is that for code systems with similarly unbounded or very large possible combinations given post-coordination grammars (e.g. UCUM and MIME) libraries of well known post-coordinated codes be defined, centralised and version managed; and that similarly expansion responses not be SUBSETTED provided they respond with all matching pre-coordinated content from the expanded version of the code system and matching expressions from the expression library.
Rationale
The recommendations are intended to
- define consistent, predictable behaviour that server implementers can create and clients can depend upon
- enable the client to determine from the server response whether all pre-coordinated (statically published) content from the code system version being expanded and all expressions explicitly included in the ValueSet are included or not
Richer responses to describe what the nature of the SUBSETTED response is were discussed however felt infeasible due to the wide variety of possible inclusions and exclusions of calculated post-coordination that could occur.
...