There isn't much consensus on requiring a resource text element, and even if there was, there is not a sufficient way of verifying the text is anything useful through the mechanisms of this IG. However, guidance will be added as defined in   FHIR-31069 . 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.