Example Usage Scenarios:

The following are example usage scenarios for this profile:

• Query for a 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 a Patient demographic information using first name, last name, birthdate, and gender.

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)
2. a patient name
3. a gender*

Each Patient Must Support:

1. a birth date
2. an address

Additional USCDI Requirements

For ONC's USCDI requirements, each Patient Must Support the following additional elements. These elements are included in the formal definition of the profile and the Patient examples.

1. contact detail (e.g. a telephone number or an email address)
2. a communication language
3. a race
4. an ethnicity
5. a tribal affiliation
6. sex*
7. gender identity*
8. date of death
9. previous address
10. previous name
11. suffix

*see guidance below

Profile Specific Implementation Guidance:

• Note that Date of Death, Previous Name, Suffix,and Previous address are listed in the U.S. Core Data for Interoperability.
  • Date of Death is communicated using the Patient.deceasedDateTime element.
  • Suffix is represented using the Patient.name.suffix element.
  • Previous name is represented by setting Patient.name.use to "old" or providing an end date in Patient.name.period or doing both.
  • Previous address is represented by setting Patient.address.use to "old" or providing an end date in Patient.address.period or doing both.
  • The Patient example demonstrates how these elements are represented.
• *US Core has reviewed and updated value sets based on input from the HL7 Gender Harmony Project which is modeling gender and sex information which includes data elements, value sets, code systems. When their work is complete, US Core will align with their recommendations. The US Core Sex Extension meets the U.S. Core Data for Interoperability (USCDI) v3 data element "sex". The US Core Birth Sex Extension is no longer a USCDI Requirement. See the FHIR specification for additional guidance and background for representing Administrative Gender, Sex assigned at Birth, and Gender Identity.
• Provenance and the FHIR Extension Target Element can be use to 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. There is increasing concern over the use of Social Security Numbers in healthcare due to the risk of identity theft and related issues. Many payers and providers have actively purged them from their systems and filter them out of incoming data.

Referenced by

Examples

Formal Views of Profile Content

Quick Start

Below is an overview of the required Server RESTful FHIR interactions for this profile - for example, search and read operations - when supporting the US Core interactions to access this profile's information (Profile Support + Interaction Support). Note that systems that support only US Core Profiles (Profile Only Support) are not required to support these interactions. See the US Core Server CapabilityStatement for a complete list of supported RESTful interactions for this IG.

• The syntax used to describe the interactions is described here.
• See the General Requirements section for additional rules and expectations when a server requires status parameters.
• See the General Guidance section for additional guidance on searching for multiple patients.

Mandatory Search Parameters:

The following search parameters and search parameter combinations SHALL be supported:

1. SHALL support both read Patient by id AND Patient search using the _id search parameter:

   GET [base]/Patient/[id] or GET [base]/Patient?_id=[id]

   Example:

   1. GET [base]/Patient/1032702
   2. GET [base]/Patient?_id=1032702

   Implementation Notes: (how to search by the logical id of the resource)

2. SHALL support searching a patient by an identifier such as a MPI using the identifier search parameter:

   GET [base]/Patient?identifier={system|}[code]

   Example:

   1. GET [base]/Patient?identifier=http://hospital.smarthealthit.org|1032702

   Implementation Notes: Fetches a bundle containing any Patient resources matching the identifier (how to search by token)

3. SHALL support searching for a patient by a server defined search that matches any of the string fields in the HumanName, including family, given, prefix, suffix, and/or text using the name search parameter:

   GET [base]/Patient?name=[string]

   Example:

   1. GET [base]/Patient?name=Shaw

   Implementation Notes: Fetches a bundle of all Patient resources matching the name (how to search by string)

4. SHALL support searching using the combination of the birthdate and name search parameters:

   GET [base]/Patient?birthdate=[date]&name=[string]

   Example:

   1. GET [base]/Patient?name=Shaw&birthdate=2007-03-20

   Implementation Notes: Fetches a bundle of all Patient resources matching the specified birthdate and name (how to search by date and how to search by string)

5. SHALL support searching using the combination of the gender and name search parameters:

   GET [base]/Patient?gender={system|}[code]&name=[string]

   Example:

   1. GET [base]/Patient?name=Shaw&gender=female

   Implementation Notes: Fetches a bundle of all Patient resources matching the specified gender and name (how to search by string and how to search by token)

Optional Search Parameters:

The following search parameter combinations SHOULD be supported:

1. SHOULD support searching using the combination of the birthdate and family search parameters:

   GET [base]/Patient?birthdate=[date]&family=[string]

   Example:

   1. GET [base]/Patient?family=Shaw&birthdate=2007-03-20

   Implementation Notes: Fetches a bundle of all Patient resources matching the specified birthdate and family (how to search by date and how to search by string)

2. SHOULD support searching using the combination of the death-date and family search parameters:

   GET [base]/Patient?death-date=[date]&family=[string]

   Example:

   1. GET [base]/Patient?family=Shaw&death-date=2022-07-22

   Implementation Notes: Fetches a bundle of all Patient resources matching the specified death-date and family (how to search by date and how to search by string)

3. SHOULD support searching using the combination of the family and gender search parameters:

   GET [base]/Patient?family=[string]&gender={system|}[code]

   Example:

   1. GET [base]/Patient?family=Shaw&gender=female

   Implementation Notes: Fetches a bundle of all Patient resources matching the specified family and gender (how to search by string and how to search by token)