

**Example Usage Scenarios:**

The following are example usage scenarios for this profile:

-   Query for Patient demographic information using Medical Record
    Number (MRN), which is a type of identifier. The MRN is identifiable
    by `identifier.system` and may be location specific.
-   Query for Patient demographic information using first name, last
    name, and birthdate.

### 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 Patient Must Have:**

1. a patient identifier (e.g., MRN)
1. a patient name

**Each Patient Must Support:**

1. a birth date
2. an address<sup>1</sup>

{% include additional-requirements-intro.md type="Patient" plural="true" %}

1. contact detail (e.g., a telephone number or an email address)
2. a communication language<sup>2</sup>
3. Interpreter Needed flag<sup>2</sup>
4. a race<sup>2</sup>
5. an ethnicity<sup>2</sup>
6. a tribal affiliation
7. sex<sup>3</sup>
8. date of death<sup>2</sup>
9. address use<sup>2</sup>
10. address period<sup>2</sup>
11. name use<sup>2</sup>
12. name period<sup>2</sup>
13. suffix<sup>2</sup>

<sup>1,2,3</sup> see guidance below

### Profile Specific Implementation Guidance

This section provides detailed implementation guidance for the US Core Profile to support implementation and certification.

- <sup>2</sup>Notes for *Race*, *Ethnicity*, *Date of Death*, *Name to Use*, *Previous Name*, *Suffix*, *Previous Address*, *Interpreter Needed*, and *Preferred Language* USCDI Data Elements:
  - The Complex Extensions for Race and Ethnicity allow for one or more codes of which: [Must Support] at least one category code from the OMB Race and Ethnicity Category Value Sets that draw from the [Race & Ethnicity - CDC (CDCREC)] code system.
    - **MAY** include additional codes from the detailed ethnicity and detailed race value sets drawn from the [Race & Ethnicity - CDC (CDCREC)] code system.<sup>[§][CONF-0461],[§][CONF-0463]</sup>
    - **SHALL** include a text description.<sup>[§][CONF-0462],[§][CONF-0464]</sup>
  - *Date of Death* is communicated using the `Patient.deceasedDateTime` element.
    - Although `Patient.deceased[x]` is marked as 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜, Certifying Systems are not required to support both, but **SHALL** support at least `Patient.deceasedDateTime`.<sup>[§][CONF-0465]</sup>
  - Systems **SHALL** represent *Previous name* by setting `Patient.name.use` to "old" or providing an end date in `Patient.name.period` or doing both.<sup>[§][CONF-0466]</sup>
  - Systems **SHALL** represent *Suffix* using the `Patient.name.suffix` element.<sup>[§][CONF-0914]</sup>
  - Systems **SHALL** represent *Previous Address* by setting `Patient.address.use` to "old" or providing an end date in `Patient.address.period` or doing both.<sup>[§][CONF-0467]</sup>
  - Servers **SHOULD** and Certifying Systems **SHALL** use the [US Core Interpreter Needed Extension] on this profile or the [US Core Encounter Profile] to communicate whether a patient needs an interpreter.<sup>[§][CONF-0851],[§][CONF-0910]</sup>
    -  Although the extension is marked as an *Additional USCDI Requirement* on both US Core Patient and US Core Encounter Profiles, the Certifying Server system is not required to support the extension on both profiles but **SHALL** support the extension on at least one.<sup>[§][CONF-0852]</sup> The Certifying Client application **SHALL** support the extension on both profiles.<sup>[§][CONF-0853],[§][CONF-0854]</sup>
     - Systems **SHOULD** designate the patient's preferred language in the `Patient.communication.preferred` element.<sup>[§][CONF-0855]</sup>
  - The [Patient example] demonstrates how these elements are represented
- <sup>1</sup>For new and updated records, [Certifying Systems] **SHALL** and non-Certifying Systems **SHOULD** enable the users who enter patient addresses to follow the [Project US@ Technical Specification for Patient Addresses Final Version 1.0], which is required by the USCDI Patient Demographics Data Class<sup>[§][CONF-0469],[§][CONF-0470]</sup>
   - Consult this specification for details about the format for the Address datatypes elements, especially `Patient.address.line` and `Patient.address.city`.
   - Note: Both Certifying and non-Certifying systems **MAY** choose not to use Project US@ for historical records or documents that are not exposed through FHIR-based APIs.<sup>[§][CONF-0471]</sup>
- <sup>1</sup>{% include should-3166-subdivision-codes.md type="Patient" %}
- <sup>3</sup>The [US Core Individual Sex Extension] represents the [U.S. Core Data for Interoperability (USCDI)] data element "Sex". Refer to the FHIR R5 [Patient] Resource for other interoperability considerations with regards to patient sex
- [Provenance] and the FHIR Extension [Target Element] can document how individual patient demographic data was captured. See [Element Level Provenance] on the [Basic Provenance] page for more information.
- The Patient's Social Security Numbers **SHOULD NOT** be used as a patient identifier in `Patient.identifier.value`.<sup>[§][CONF-0472]</sup> There is increasing concern over using Social Security Numbers in healthcare due to the risk of identity theft and related issues. Many payers and providers have purged them from their systems and filtered them out of incoming data.

{% include link-list.md %}
