Purpose
This page is intended to capture the majority position on the issue of the behaviour of the $expand operation relative to SNOMED CT editions and post-coordination - a topic that has been greatly discussed.
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 "includePostCooridinated" 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
Rationale
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 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. 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 specification.
Were servers 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 "too costly" response in a common case is not useful, the SUBSETTED response is useful however it does not allow the client to understand what may be omitted in the subset and whether it is usable, and may vary per server.
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.
Adding the requirement that any $expand result that is SUBSETTED must require at least all matching pre-coordinated SNOMED CT content provides clients a guarantee that if they specify "includePostCoordinated" as true, any SUBSETTED response (which they are highly likely to get) will not omit pre-coordinated content. This allows servers that are able to implement calculated post-coordination in some way (e.g. just laterality) and clients that wish to use that functionality the ability to do so with extra clarity around the SUBSETTED response they exchange.
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.
The behaviour of $validate-code and code:in should remain unchanged as defaults match most likely expected behaviour - post-coordinated expressions tested against $validate-code or code:in should return true if they meet the ValueSet definition. Unlike the case of $expand, these cases involve the client specifying a finite set of post-coordinated expressions to the server and are hence considered tractable, unlike the case of $expand that requires calculating an unbounded or extremely large set of expressions most of which are unlikely to be used.