US Core Implementation Guide
8.0.0 - STU 8 United States of America flag

US Core Implementation Guide, published by HL7 International / Cross-Group Projects. This guide is not an authorized publication; it is the continuous build for version 8.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/US-Core/ and changes regularly. See the Directory of published versions

Resource Profile: US Core Patient Profile

Official URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient Version: 8.0.0
Standards status: Trial-use Computable Name: USCorePatientProfile
Other Identifiers: OID:2.16.840.1.113883.4.642.40.2.42.49

Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

The US Core Patient Profile inherits from the FHIR Patient resource; refer to it for scope and usage definitions. This profile meets the requirements of the U.S. Core Data for Interoperability (USCDI) Patient Demographics/Information Data Class. It sets minimum expectations for the Patient resource to record, search, and fetch basic demographics and other administrative information about an individual patient. It specifies which core elements, extensions, vocabularies, and value sets SHALL be present and constrains how the elements are used. Providing the floor for standards development for specific use cases promotes interoperability and adoption.

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, 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:

These Additional USCDI Requirements elements are not Mandatory or Must Support but are required for ONC Health IT certification testing and 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. Interpreter Needed flag*
  4. a race*
  5. an ethnicity*
  6. a tribal affiliation
  7. sex*
  8. sex parameter for clinical use*
  9. gender identity*
  10. personal pronouns
  11. date of death*
  12. address use*
  13. address period*
  14. name use*
  15. name period*
  16. suffix*

*see guidance below

Profile Specific Implementation Guidance:

  • 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 Categories
      • MAY include additional detailed codes from CDC Race and Ethnicity Codes
      • SHALL include a text description
    • 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
    • Name to Use is represented by setting Patient.name.use to "usual".
    • Previous name is represented by setting Patient.name.use to "old" or providing an end date in Patient.name.period or doing both.
    • Suffix is represented using the Patient.name.suffix element.
    • Previous Address is represented by setting Patient.address.use to "old" or providing an end date in Patient.address.period or doing both.
    • Servers can use the US Core Interpreter Needed Extension on the US Core Patient or [US Core Encounter Profiles] to communicate whether a patient needs an interpreter. 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. The certifying Client application SHALL support the extension on both profiles.
      • When multiple languages are represented, systems MAY designate the patient's Preferred Language in the Communication.preferred element or by using the FHIR standard Patient Proficiency Extension and infer a patient's language service needs from it.
    • The Patient example demonstrates how these elements are represented.

  • The USCDI Patient Demographics Data Class requires following the Project US@ Technical Specification for Patient Addresses Final Version 1.0 for patient addresses. For new and updated records, Certifying Systems SHALL and non-Certifying Systems SHOULD follow it as the standard style guide for Patient addresses.

    • Consult the style guide for details about the format for the Address datatypes elements, especially Patient.address.line and Patient.address.city.

    • Note: historical records or documents that are not exposed through FHIR-based APIs may not meet this requirement.

  • *US Core aligns with the HL7 Gender Harmony Project gender and sex information, which includes data elements, value sets, and code systems. Refer to it and the FHIR R5 Patient Resource Gender and Sex Notes for additional guidance and background for representing Administrative Gender, Sex Assigned at Birth, Gender Identity, and Sex Parameter For Clinical Use (SPCU) Note that:

US Core certified systems are required to support the Patient Sex Parameter For Clinical Use extension on US Core Patient to support at least a patient-level context. Systems SHOULD also use the extension on other US Core Profiles for specific clinical contexts when appropriate, for example, on US Core Observation when interpreting a laboratory result. However, this extension is not used in contexts such as "Ask at Order Entry" (AOE) questions for laboratory testing orders, typically communicated using Observation. With more implementation experience and user feedback, US Core may provide additional guidance for using this extension with other US Core Profiles.

  • 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. 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.

Usage:

Changes since version 7.0.0:

  • The resource metadata has changed (description)
  • The data elements list has changed
  • One or more text definitions, invariants or bindings have changed

    • Formal Views of Profile Content

    Description of Profiles, Differentials, Snapshots and how the different presentations work.

    NameFlagsCard.TypeDescription & Constraintsdoco
    .. Patient 0..* Patient Information about an individual or animal receiving health care services
    dom-2: If the resource is contained in another resource, it SHALL NOT contain nested Resources
    dom-3: If the resource is contained in another resource, it SHALL be referred to from elsewhere in the resource or SHALL refer to the containing resource
    dom-4: If a resource is contained in another resource, it SHALL NOT have a meta.versionId or a meta.lastUpdated
    dom-5: If a resource is contained in another resource, it SHALL NOT have a security label
    dom-6: A resource should have narrative for robust management
    ... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
    ele-1: All FHIR elements must have a @value or children
    ... Slices for extension Content/Rules for all slices
    .... extension:race C 0..1 (Complex) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: US Core Race Extension. (multiple races are supported in the extension)
    URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-race
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    us-core-23: If "ASKU" or "UNK" are present, then no other OMB race categories can be present.
    .... extension:ethnicity 0..1 (Complex) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: US Core ethnicity Extension (multiple ethnicities are supported in the extension)
    URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... extension:tribalAffiliation 0..* (Complex) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Tribal Affiliation Extension
    URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-tribal-affiliation
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... extension:birthsex 0..1 code Birth Sex Extension
    URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex
    Binding: Birth Sex . (required): Code for sex assigned at birth


    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... extension:sex 0..1 code 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Sex Extension
    URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-sex
    Binding: Sex . (extensible): Concepts used for general documentation of sex representation


    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... extension:sexParameterForClinicalUse 0..* (Complex) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Sex Parameters for Clinical Use Extension
    URL: http://hl7.org/fhir/StructureDefinition/patient-sexParameterForClinicalUse
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... extension:genderIdentity 0..* CodeableConcept 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The individual's gender identity
    URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-genderIdentity
    Binding: Gender Identity . (extensible)
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... extension:personalPronouns 0..* (Complex) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Individual's Pronouns Extension
    URL: http://hl7.org/fhir/StructureDefinition/individual-pronouns
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... extension:interpreterRequired 0..1 Coding 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Whether the patient needs an interpreter
    URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-interpreter-needed
    Binding: Answer Set with Yes No and Unknowns . (required): Answer Set with Yes No and Unknowns


    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    ... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    ... identifier SΣ 1..* Identifier An identifier for this patient
    ele-1: All FHIR elements must have a @value or children
    .... use ?!Σ 0..1 code usual | official | temp | secondary | old (If known)
    Binding: IdentifierUse (required): Identifies the purpose for this identifier, if known .


    ele-1: All FHIR elements must have a @value or children
    .... system SΣ 1..1 uri The namespace for the identifier value
    ele-1: All FHIR elements must have a @value or children
    Example General: http://www.acme.com/identifiers/patient
    .... value SΣ 1..1 string The value that is unique within the system.
    ele-1: All FHIR elements must have a @value or children
    Example General: 123456
    ... active ?!Σ 0..1 boolean Whether this patient's record is in active use
    ele-1: All FHIR elements must have a @value or children
    ... name SΣC 1..* HumanName A name associated with the patient
    ele-1: All FHIR elements must have a @value or children
    us-core-6: At least name.given and/or name.family are present or, if neither is available, the Data Absent Reason Extension is present.
    .... use ?!Σ 0..1 code 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: usual | official | temp | nickname | anonymous | old | maiden
    Binding: NameUse (required): The use of a human name.


    ele-1: All FHIR elements must have a @value or children
    .... family SΣC 0..1 string Family name (often called 'Surname')
    ele-1: All FHIR elements must have a @value or children
    .... given SΣC 0..* string Given names (not always 'first'). Includes middle names
    ele-1: All FHIR elements must have a @value or children
    This repeating element order: Given Names appear in the correct order for presenting the name
    .... suffix Σ 0..* string 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Parts that come after the name
    ele-1: All FHIR elements must have a @value or children
    This repeating element order: Suffixes appear in the correct order for presenting the name
    .... period Σ 0..1 Period 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Time period when name was/is in use
    ele-1: All FHIR elements must have a @value or children
    ... telecom Σ 0..* ContactPoint 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: A contact detail for the individual
    ele-1: All FHIR elements must have a @value or children
    .... system SΣC 1..1 code phone | fax | email | pager | url | sms | other
    Binding: ContactPointSystem (required): Telecommunications form for contact point.


    ele-1: All FHIR elements must have a @value or children
    .... value SΣ 1..1 string The actual contact point details
    ele-1: All FHIR elements must have a @value or children
    .... use ?!SΣ 0..1 code home | work | temp | old | mobile - purpose of this contact point
    Binding: ContactPointUse (required)
    ele-1: All FHIR elements must have a @value or children
    ... gender SΣ 1..1 code male | female | other | unknown
    Binding: AdministrativeGender (required)
    ele-1: All FHIR elements must have a @value or children
    ... birthDate SΣ 0..1 date The date of birth for the individual
    ele-1: All FHIR elements must have a @value or children
    ... deceased[x] ?!Σ 0..1 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Indicates if the individual is deceased or not
    ele-1: All FHIR elements must have a @value or children
    .... deceasedBoolean boolean
    .... deceasedDateTime dateTime
    ... address SΣ 0..* Address An address for the individual
    ele-1: All FHIR elements must have a @value or children
    .... use ?!Σ 0..1 code 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: home | work | temp | old | billing - purpose of this address
    Binding: AddressUse (required): The use of an address.


    ele-1: All FHIR elements must have a @value or children
    Example General: home
    .... line SΣ 0..* string Street name, number, direction & P.O. Box etc.
    ele-1: All FHIR elements must have a @value or children
    This repeating element order: The order in which lines should appear in an address label
    Example General: 137 Nowhere Street
    Example General: 49 MEADOW ST
    .... city SΣ 0..1 string Name of city, town etc.
    ele-1: All FHIR elements must have a @value or children
    Example General: Erewhon
    Example General: EVERYTOWN
    .... state SΣ 0..1 string Sub-unit of country (abbreviations ok)
    Binding: USPS Two Letter Alphabetic Codes (extensible): Two Letter USPS alphabetic codes.


    ele-1: All FHIR elements must have a @value or children
    Example General: OK
    .... postalCode SΣ 0..1 string US Zip Codes
    ele-1: All FHIR elements must have a @value or children
    Example General: 9132
    Example General: 74047
    .... period Σ 0..1 Period 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Time period when address was/is in use
    ele-1: All FHIR elements must have a @value or children
    Example General: {"start":"2010-03-23","end":"2010-07-01"}
    ... communication 0..* BackboneElement 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: A language which may be used to communicate with the patient about his or her health
    ele-1: All FHIR elements must have a @value or children
    .... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... language S 1..1 CodeableConcept The language which can be used to communicate with the patient about his or her health
    Binding: Language codes with language and optionally a region modifier (extensible)
    ele-1: All FHIR elements must have a @value or children
    ... link ?!Σ 0..* BackboneElement Link to another patient resource that concerns the same actual person
    ele-1: All FHIR elements must have a @value or children
    .... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
    ele-1: All FHIR elements must have a @value or children
    ext-1: Must have either extensions or value[x], not both
    .... other Σ 1..1 Reference(Patient | RelatedPerson) The other patient or related person resource that the link refers to
    ele-1: All FHIR elements must have a @value or children
    .... type Σ 1..1 code replaced-by | replaces | refer | seealso
    Binding: LinkType (required): The type of link between this patient resource and another patient resource.


    ele-1: All FHIR elements must have a @value or children

    doco Documentation for this format

    Terminology Bindings

    PathConformanceValueSetURI
    Patient.identifier.userequiredIdentifierUse
    http://hl7.org/fhir/ValueSet/identifier-use|4.0.1
    from the FHIR Standard
    Patient.name.userequiredNameUse
    http://hl7.org/fhir/ValueSet/name-use|4.0.1
    from the FHIR Standard
    Patient.telecom.systemrequiredContactPointSystem
    http://hl7.org/fhir/ValueSet/contact-point-system
    from the FHIR Standard
    Patient.telecom.userequiredContactPointUse
    http://hl7.org/fhir/ValueSet/contact-point-use
    from the FHIR Standard
    Patient.genderrequiredAdministrativeGender
    http://hl7.org/fhir/ValueSet/administrative-gender
    from the FHIR Standard
    Patient.address.userequiredAddressUse
    http://hl7.org/fhir/ValueSet/address-use|4.0.1
    from the FHIR Standard
    Patient.address.stateextensibleUspsTwoLetterAlphabeticCodes (a valid code from https://www.usps.com/)
    http://hl7.org/fhir/us/core/ValueSet/us-core-usps-state
    from this IG
    Patient.communication.languageextensibleLanguageCodesWithLanguageAndOptionallyARegionModifier
    http://hl7.org/fhir/us/core/ValueSet/simple-language
    from this IG
    Patient.link.typerequiredLinkType
    http://hl7.org/fhir/ValueSet/link-type|4.0.1
    from the FHIR Standard

    Constraints

    IdGradePath(s)DetailsRequirements
    us-core-6errorPatient.nameAt least name.given and/or name.family are present or, if neither is available, the Data Absent Reason Extension is present.
    : (family.exists() or given.exists()) xor extension.where(url='http://hl7.org/fhir/StructureDefinition/data-absent-reason').exists()

     

    Other representations of profile: CSV, Excel, Schematron

    Notes:

    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.

    • See the Scopes Format section for a description of the SMART scopes syntax.
    • See the Search Syntax section for a description of the US Core search syntax.
    • 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.

    US Core Scopes

    Servers providing access to patient data SHALL support these US Core SMART Scopes:

    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)