Comment:

Two needs exist: 1) The need to express the laterality and relative position of a body site in a structured, post-coordinated fashion. In this case, there's no need to identify the site – codes are sufficient to convey the location. For example, to express that a measurement was taken from the right index finger or that the left forearm was bruised, certainly the right index finder and left forearm are specific sites, but they needn't be assigned identifiers. 2) The need to identify a body site. For example, identifying a specimen or the specific sites of wounds (when the patient has multiple wounds) or of chest tubes (when the patient has multiple tubes). The body site resource seems to be attempting to solve both needs, whereas it might be better to separate the two needs and use different solutions for each. For need #1, a full resource requiring a patient id is undue complexity. All that is needed is an inline complex element or data type that contains a CodeableConcept for the "main" location plus sub-elements of "laterality" and "relatedness" (proximal, upper, etc.). (There was a lot of discussion about the correct attributes, and in the end it appears it was just reduced to a single "modifier" element, but this is insufficiently exact in its semantics. At least a 0..* name/value pair is needed.) If further detail is needed (e.g., relation to some other body site), another complex type (either a separate type or a generalization of this one) could be constructed. Or maybe resources (like Observation) have just misused this resource. The text of Body Site says, "The BodySite resource is not intended to substitute for precoordination of codes. If precoordination of codes is supported by an implementation and a resource element has a choice of codeableConcept or BodySite, the codeableConcept should be used." But the problems are that a single CodeableConcept is insufficient for Observation's site and there is no complex structure to use instead.