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

Improve narrative guidance on the requirement for coding.code and text to be semantically equivalent

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US CARIN Blue Button (FHIR)
    • current
    • Financial Mgmt
    • C4BB Explanation Of Benefit
    • Hide

      There is not much that can be done regarding strict constraints within the scope of an interoperability FHIR implementation guide. However, we will add the following guidance to the guide that will make the situation clear and note considerations for code display values, text rendering as defined in the resolution in  FHIR-31069.

      Summarized for this ticket:

      Add guidance in general guidance section (under CapabilityStatement Server Requirement) called "Payer Considerations for App Rendering"

      Many of the codes used in this guide are proprietary with [licensing requirements](Terminology.html). While it is recommended that consumer apps acquire the necessary licenses to show descriptions for these codes, not all app developers may be in a position to do so. Because of this, payers MAY choose to provide a concept text `[CodeableConcept].text` or the coding display `[CodeableConcept].coding.display. It is the responsibility of the payer to make sure that the descriptions provided are correct.

       

      If the 'display' element is populated, the string used in `displaySHALL be one of the display strings defined for that code by the code system (code systems may define multiple display strings for a single code).

      With the additional statement noting that "If the code description available is not known to be an exact match of a display string defined by the code system, the  `[CodeableConcept].text` should be used in place of the `[CodeableConcept].coding.display`."

      Show
      There is not much that can be done regarding strict constraints within the scope of an interoperability FHIR implementation guide. However, we will add the following guidance to the guide that will make the situation clear and note considerations for code display values, text rendering as defined in the resolution in   FHIR-31069 . Summarized for this ticket: Add guidance in general guidance section (under CapabilityStatement Server Requirement) called "Payer Considerations for App Rendering" Many of the codes used in this guide are proprietary with  [licensing requirements] (Terminology.html). While it is recommended that consumer apps acquire the necessary licenses to show descriptions for these codes, not all app developers may be in a position to do so. Because of this, payers  MAY  choose to provide a concept text ` [CodeableConcept] .text` or the coding display ` [CodeableConcept] .coding.display. It is the responsibility of the payer to make sure that the descriptions provided are correct.   If the 'display' element is populated, the string used in ` display `  SHALL  be one of the display strings defined for that code by the code system (code systems may define multiple display strings for a single code). With the additional statement noting that  "If the code description available is not known to be an exact match of a display string defined by the code system, the  ` [CodeableConcept] .text` should be used in place of the ` [CodeableConcept] .coding.display`."
    • Corey Spears / Mary Kay McDaniel: 9-0-0
    • Clarification
    • Non-substantive
    • Yes
    • current

    Description

      During testing we are seeing examples where the coding of an element and its corresponding text are not semantically the same. Because this is a difficult error to detect without manual inspection, server systems MUST be responsibly designed to avoid this error when the data is served to a client system. 

      The IG needs to do more to make this server-side responsibility very clear and manual inspection for this issue needs to be highlighted during Connectathon testing.

      See slide 4 for an example.

       

      Attachments

        Activity

          People

            Unassigned Unassigned
            LisaRNelson Lisa R. Nelson
            Lisa R. Nelson
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: