Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-29563

Extensible bindings including broad SNOMED CT value sets are nonsensical



    • Change Request
    • Status: Published (View Workflow)
    • Medium
    • Resolution: Persuasive


      There are a number of US core profiles (e.g. Procedure, Condition) where the value set is defined as 'extensible' but the value set is defined as including high level SNOMED CT codes and their specializations.  E.g. "Procedure or a specialization there-of".  The effect of this is that there cannot EVER be a concept that isn't covered by one of the codes from the value set.  At minimum, one can always send the SNOMED CT 'Procedure' code for a FHIR Procedure - and thus there is never a situation where it's conformant to send a US Core Procedure instance that has just text or doesn't include a code from the bound value set.

      As a result, the 'extensible' binding is likely to create confusion amongst implementers.

      The profiles should be changed in one of two ways - either mark the bindings as 'required' (with an explanation to use the high-level SNOMED code if nothing else applies) or refine the value set to exclude the higher level 'abstract' SNOMED codes so that there are actually situations where there genuinely might not be an applicable SNOMED code and where text or an external code would apply.

      Please note: your intentions/desires here don't impact the formal interpretation of the binding.  Anyone who sends just a local code or free text in a Procedure.code or Condition.code right now is clearly and definitively non-conformant with the constraints of the IG according to FHIR's conformance rules.


        Issue Links



              Unassigned Unassigned
              lloyd Lloyd McKenzie
              7 Start watching this issue