2015May core #882 - Don't allow local/proprietary codes

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU1 [deprecated]
    • Terminology Infrastructure
    • Profiling
    • 2.14.0.11 Mixing Cus
    • Hide

      Add sentence noting that local codes are not as interoperable as publicly defined codes.

      Show
      Add sentence noting that local codes are not as interoperable as publicly defined codes.
    • Grahame Grieve / Eric Haas: 4-0-0
    • Enhancement
    • Non-substantive
    • DSTU1 [deprecated]

      Existing Wording: Value Set resources can be used to define local codes (Example) and to mix a combination of local codes and standard codes (examples: LOINC, SNOMED), or just to choose a particular set of standard codes (examples: LOINC, SNOMED, RxNorm). Profiles can bind to these value sets instead of the ones defined in the base specification, following these rules

      Comment:

      This section seems to suggest that "custom" or "local" or "proprietary" codes could be included in profile value set constraint. For interoperability profiles should not allow the addition of proprietary codes. If this not what this section is promoting please clarify what "mixing custom and standard" or "local codes" means.

      If the "local codes" refer to local extensions of standard terminology that are subject for additional harmonization and inclusion in the value set and source coding system, that would perfect. Otherwise, the additonal of local/proprietary/custom codes would be detrimental to interoperability.

            Assignee:
            Unassigned
            Reporter:
            Ioana Singureanu
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: