Example Usage Scenarios:

The following are example usage scenarios for this profile:

• Query for a specific patient encounter
• Query for recent patient encounters
• Record or update an encounter

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 Encounter Must Have:

1. A status
2. A classification such as inpatient, outpatient, or emergency
3. An encounter type
4. A patient

Each Encounter Must Support:

1. A timestamp when the resource last changed*
2. An encounter identifier
3. Providers involved in the encounter
4. When the encounter occurred
5. Reason for the visit
6. The discharge disposition
7. Where the encounter occurred

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. Interpreter Needed flag*

*see guidance below

Profile Specific Implementation Guidance:

• To search for an encounter diagnosis, query for Condition resources that reference the Encounter of interest and have a category of encounter-diagnosis. An example search is shown in the Condition Quick Start section.
• The Encounter resource can represent a reason using a code with Encounter.reasonCode or a reference with Encounter.reasonReference to Condition or other resources.
  • Although both are marked as Must Support, Servers are not required to support both a code and a reference, but they SHALL support at least one of these elements.
  • The Client application SHALL support both elements.
  • If Encounter.reasonReference references an Observation, it SHOULD conform to a US Core Observation if applicable. For example, a laboratory result SHOULD conform to the US Core Laboratory Result Observation Profile.
• This profile supports where the encounter occurred. The location address can be represented by the Location referenced by Encounter.location.location or indirectly through the Organization referenced by Encounter.serviceProvider.
  • Although both are marked as Must Support, Servers are not required to support both Encounter.location.location and Encounter.serviceProvider, but they SHALL support at least one of these elements.
  • The Client application SHALL support both elements.
• The following US Core Profiles indirectly reference the location/facility through references to US Core Encounter:
  • US Core DiagnosticReport Profile for Laboratory Results Reporting
  • US Core Immunization Profile
  • US Core MedicationDispense Profile
  • US Core Observation Clinical Result Profile
  • US Core Procedure Profile
  • US Core ServiceRequest Profile

  If the event facility/location differs from the Encounter.location, systems SHOULD reference it directly:

  • Systems SHALL use the location element for all resources where the element is available.
  • Systems MAY use the standard Event Location Extension for US Core DiagnosticReport Profile for Laboratory Results Reporting and US Core Observation Clinical Result Profile.
• *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 Requirements 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.
  • System can communicate the patient's language preferences in the Patient.language element and the optional Patient Proficiency Extension and infer a patient's language service needs from it.
• * See the US Core General Guidance page for Searching Using lastUpdated. Updates to Meta.lastUpdated SHOULD reflect:
  • New encounters/visits
  • Changes in the status of encounters, including events that trigger the same status (e.g., in-progress → in-progress). These status changes correspond to events that can initiate HL7 V2 ADT messages.

Changes since version 7.0.0:

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 encounter data SHALL support these US Core SMART Scopes:

• resource level scopes: <patient|user|system>/Encounter.rs

Mandatory Search Parameters:

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

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

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

   Example:

   1. GET [base]/Encounter/12354
   2. GET [base]/Encounter?_id=12354

   Implementation Notes: Fetches a single Encounter (how to search by the logical id of the resource)

2. SHALL support searching for all encounters for a patient using the patient search parameter:

   GET [base]/Encounter?patient={Type/}[id]

   Example:

   1. GET [base]/Encounter?patient=1137192

   Implementation Notes: Fetches a bundle of all Encounter resources for the specified patient (how to search by reference)

3. SHALL support searching using the combination of the date and patient search parameters:

   • including support for these date comparators: gt,lt,ge,le
   • including optional support for AND search on date (e.g.date=[date]&date=[date]]&...)

   GET [base]/Encounter?date={gt|lt|ge|le}[date]{&date={gt|lt|ge|le}[date]&...}&patient={Type/}[id]

   Example:

   1. GET [base]/Encounter?patient=example1&date=ge2019-01-01T00:00:00Z

   Implementation Notes: Fetches a bundle of all Encounter resources matching the specified date and patient (how to search by date and how to search by reference)

Optional Search Parameters:

The following search parameter combinations SHOULD be supported:

1. SHOULD support searching for an encounter by an identifier using the identifier search parameter:

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

   Example:

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

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

2. SHOULD support searching using the combination of the class and patient search parameters:

   GET [base]/Encounter?class={system|}[code]&patient={Type/}[id]

   Example:

   1. GET [base]/Encounter?patient=example1&class= http://terminology.hl7.org/CodeSystem/v3-ActCode code|AMB

   Implementation Notes: Fetches a bundle of all Encounter resources matching the specified class and patient (how to search by reference and how to search by token)

3. SHOULD support searching using the combination of the patient and type search parameters:

   GET [base]/Encounter?patient={Type/}[id]&type={system|}[code]

   Example:

   1. GET [base]/Encounter?patient=1137192&type=http://www.ama-assn.org/go/cpt code|99211

   Implementation Notes: Fetches a bundle of all Encounter resources matching the specified patient and type (how to search by reference and how to search by token)

4. SHOULD support searching using the combination of the patient and location search parameters:

   GET [base]/Encounter?patient={Type/}[id]&location={Type/}[id]

   Example:

   1. GET [base]/Encounter?patient=1137192&location=Location/hospital

   Implementation Notes: Fetches a bundle of all Encounter resources matching the specified patient and location (how to search by reference)

5. SHOULD support searching using the combination of the patient and status search parameters:

   GET [base]/Encounter?patient={Type/}[id]&status={system|}[code]

   Example:

   1. GET [base]/Encounter?patient=example1&status=finished

   Implementation Notes: Fetches a bundle of all Encounter resources matching the specified patient and status (how to search by reference and how to search by token)

6. SHOULD support searching using the combination of the patient and discharge-disposition search parameters:

   GET [base]/Encounter?patient={Type/}[id]&discharge-disposition={system|}[code]

   Example:

   1. GET [base]/Encounter?patient=example1&discharge-disposition=01

   Implementation Notes: Fetches a bundle of all Encounter resources matching the specified patient and discharge-disposition (how to search by reference and how to search by token)

7. SHOULD support searching using the combination of the patient and _lastUpdated search parameters:

   • including support for these _lastUpdated comparators: gt,lt,ge,le
   • including optional support for AND search on _lastUpdated (e.g._lastUpdated=[date]&_lastUpdated=[date]]&...)

   GET [base]/Encounter?patient={Type/}[id]&_lastUpdated={gt|lt|ge|le}[date]{&_lastUpdated={gt|lt|ge|le}[date]&...}

   Example:

   1. GET [base]/Encounter?patient=1137192&_lastUpdated=ge2024-01-01T00:00:00Z

   Implementation Notes: Fetches a bundle of all Encounter resources for the specified patient and _lastUpdated. See the US Core General Guidance page for Searching Using lastUpdated. (how to search by reference and how to search by date)