

**Example Usage Scenarios:**

The following are example usage scenarios for the US Core ADI DocumentReference profile:

-   Query for all ADI documents belonging to a Patient
-   Query for a specific ADI Document type (e.g., POLST or Living Will)

### Mandatory and Must Support Data Elements

The following data elements must always be present ([Mandatory] definition) or must be supported if the data is present in the sending system ([Must Support] definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The [Formal Views] below provides the formal summary, definitions, and terminology requirements.

**Each DocumentReference Must Have:**

1. a status
2. a code describing the type of ADI document (for example, POLST or Living Will)
3. an ADI document category (for example, Advance Directives)
4. a patient
5. document referenced (content)
6. the MIME type (i.e., contentType) of the document

**Each DocumentReference Must Support:**

1. a business identifier for the DocumentReference (possibly generated by the transcription system or EHR)
1. date and time the DocumentReference was created
1. an author<sup>1</sup>
2. a code identifying the specific implementation requirements that the document conforms to  — over and above the content's MIME type

<!-- {% raw %} {% include additional-requirements-intro.md type="DocumentReference" %}
 {% endraw %} -->

<sup>1</sup> see guidance below

### Profile Specific Implementation Guidance

This section provides detailed implementation guidance for the US Core Profile to support implementation and certification.
- This profile and the [US Core Observation ADI Documentation Profile] meet the [U.S. Core Data for Interoperability (USCDI)] *Advance Directive Observation* Data Element requirements.
- This profile can communicate the contents of a Portable Medical Order (PMO) document, such as POLST, MOLST, or other state-specific forms, satisfying USCDI's *Portable Medical Order* Data Element requirements.
  - The [US Core ServiceRequest Profile] can be used to represent a derived "actionable" order based on a PMO.
- In addition to the [Advance Directive Categories](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.69.4/expansion) value set, other category schemes may be used to facilitate the sharing of health documents.

- The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using `DocumentReference.content.attachment.url` or the content as inline base64 encoded data using `DocumentReference.content.attachment.data`.
    -  Although both are marked as Must Support, the Server system is not required to support an address and inline base64 encoded data, but **SHALL** support at least one of these elements.<sup>[§][CONF-0368]</sup>
    -  The Client application **SHALL** support both elements.<sup>[§][CONF-0369],[§][CONF-0370]</sup>
    -  The `DocumentReference.content.attachment.url` may refer to a FHIR Binary Resource (i.e., [base]/Binary/[id]), FHIR Document Bundle (i.e., [base]/Bundle/[id], or another endpoint).
        - If the referenced document or file is hosted on a server outside the FHIR server, it **SHOULD** be securely accessible using the same authorization credentials that were used to access the FHIR server.<sup>[§][CONF-0839]</sup> This reduces complexity for the client and improves the user experience.
    -  If there are multiple `DocumentReference.content` element repetitions, these **SHALL** all represent the same document in different formats or attachment metadata.<sup>[§][CONF-0372]</sup> The content element **SHALL NOT** contain different versions of the same content.<sup>[§][CONF-0373]</sup> For version handling, use multiple DocumentReferences with `DocumentReference.relatesTo`.
- Every DocumentReference must have a responsible Organization. The organization responsible for the DocumentReference **SHALL** be present either in `DocumentReference.custodian` or accessible in the Provenance resource targeting the DocumentReference using `Provenance.agent.who` or `Provenance.agent.onBehalfOf`.<sup>[§][CONF-0374]</sup>
   - Some systems may also expose the same organization in referenced Encounter in `Encounter.serviceProvider`.
{% include provenance-author-bullet-generator.md footnote-symbol="<sup>1</sup>" %}
- To represent the patient and provider attestation metadata, the *optional* DocumentReference Attestor R5 Extension in the formal definition below **SHOULD** be used.<sup>[§][CONF-0899]</sup> The examples associated with this profile illustrate how it is populated for various ADI documents.

{% include link-list.md %}
