These are challenging issues. 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, and API documentation that is targeted towards raising awareness and supplying implementers with information they can use to create better implementations.   Make the following changes 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`."   Payers  MAY  choose to also provide resource level text to enable consumers apps to render resources in a manner that the payer would like to have the data presented. The ` [Resource] .text` is a Narrative datatype that has a `div` element that is an xhtml datatype. This element  MAY  be used to provide an easily renderable version of the resource that is meant for human viewing. This capability may be of particular interest to payers for ExplanationOfBenefit resources and can be used to enable the rendering of the Explanation of Benefit data in a fashion similar to their mailed or portal accessible Explanation of Benefit documents. Explanation of Benefit information can be complex. Many of the data elements in this guide go beyond what is commonly included in printed Explanation of Benefit documents today. Payers may also provide additional data elements beyond what is in this guide. As part of their API documentation, Payers  SHOULD  include descriptions of the data elements they provide, particularly for data elements not covered in this guide, and may consider providing a display mapping like can be found in the  [Example ExplanationOfBenefit Render Mapping] (#example-eob-render-mapping) section of this implementation guide.   Add guidance in general guidance section (under "Payer Considerations for App Rendering") called "Example ExplanationOfBenefit Render Mapping" Explanation Of Benefits documents that are either mailed in a physical form or downloaded through a member portal vary widely from payer to payer. There is no such thing as a standardized Explanation Of Benefits document format. There are some common elements across many of these documents, such as how much was charged by a provider and how much is covered by the insurance, but the manner in which this data is presented is determined by the individual payer. The information found in payer Explanation Of Benefits documents represent only a subset of the data that may be available through the use of the profiles defined in this implementation guide. Printed Explanation of Benefits documents usually present a member friendly overview of services, charges, cost sharing, and benefits and do not usually contain the claim details or other more detailed codified and discrete data made available through this implementation guide's profiles. Below is an example generic Explanation Of Benefits document that represents some of the information one might find from payers. This example is not exhaustive, but does present some common information found on these documents. As shown in this example document, payers may include more than one claim on a single explanation of benefit document. The ExplanationOfBenefit profiles in this guide address a single claim. In this example there would be two ExplanationOfBenefit resources, one for each claim, that both relate to this one "printed" document. Below is an example mapping from these informational elements to CPCDS data elements and specific resource data element paths. This mapping can be used by app developers as guidance to understanding how information found on EOB documents relate to the profiles in this guide. This mapping can also be used by payers as guidance for how they could further develop their API documentation to enable client apps connecting to their API. [Insert material from attached Example EOB mapping document]