eLTSS Server - Electronic Long-Term Services and Supports (eLTSS) Release 1

This page is part of the electronic Long-Term Services and Supports Implementation Guide (v2.0.0: STU2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

CapabilityStatement: eLTSS Server

Official URL: http://hl7.org/fhir/us/eltss/CapabilityStatement/eltss-server		Version: 2.0.0
Standards status: Trial-use	Maturity Level: 2	Computable Name: ELTSSSERVERCAPABILITYSTATEMENT
Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

This Section describes the expected capabilities of the eLTSS/US Core Server actor which is responsible for providing responses to the queries submitted by the eLTSS/US Core Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by eLTSS/US Core Servers are defined. Systems implementing this capability statement should meet the ONC 2015 Common Clinical Data Set (CCDS) access requirement for Patient Selection 170.315(g)(7) and Application Access - Data Category Request 170.315(g)(8) and the ONC U.S. Core Data for Interoperability (USCDI) Version 3 July 2022. eLTSS/US Core Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

Raw OpenAPI-Swagger Definition file | Download

eLTSS Server Capability Statement

Implementation Guide Version: 2.0.0
FHIR Version: 4.0.1
Supported Formats: SHALL support json, SHOULD support xml
Supported Patch Formats: SHOULD support application/json-patch+json
Published on: 2023-11-20 00:35:01-0800
Published by: HL7 International / Human and Social Services

Note to Implementers: FHIR Capabilities
Any FHIR capability may be 'allowed' by the system unless explicitly marked as "SHALL NOT". A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.
This requirements capability statement imports the entirety of the US Core Server CapabilityStatement from US Core. Refer to the imported capability statement for full information on the capabilities defined by this capability statement.

The imports field in the JSON indicates from which capability statements an IG imports. As an implementer, you can think of this as similar to profiling. This means that the expectation of this Server Capability statement is that the entire US Core capability statement will be conformed too, in addition to specifications that follow. The JSON/XML version of the CapabilityStatement is the computable specification. This narrative is for convenience only.

SHALL Support the Following Implementation Guides

SHOULD Support the Following Implementation Guides

FHIR RESTful Capabilities

Mode: `server`

The eLTSS/US Core Server SHALL:

Support the eLTSS Patient resource profile AND at least one additional resource profile from the list of eLTSS/US Core Profiles AND all Must Support eLTSS/US Core Profiles and resources it references.
- The tables below summarizes the Must Support references to other eLTSS/US Core Profiles and FHIR resources for each eLTSS/US Core Profile:
Implement the RESTful behavior according to the FHIR specification.
Follow the requirements documented in the General Requirements and Must Support pages
Return the following response classes:
- (Status 400): invalid parameter
- (Status 401/4xx): unauthorized request
- (Status 403): insufficient scopes
- (Status 404): unknown resource
Support JSON source formats for all eLTSS/US Core interactions.

The eLTSS/US Core Server SHOULD:

Follow the guidance documented in the General Guidance page
Support XML source formats for all eLTSS/US Core interactions.
Identify the eLTSS/US Core profiles supported as part of the FHIR meta.profile attribute for each instance.

Security

See the General Security Considerations section for requirements and recommendations.

A server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found"

Summary of System-wide Interactions

MAY support the transaction interaction.
MAY support the batch interaction.
MAY support the search-system interaction.
MAY support the history-system interaction.

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

The relevant profiles (if any)
The required, recommended, and some optional search parameters (if any).
The linked resources enabled for _include
The other resources enabled for _revinclude
The operations on the resource (if any)

Resource Type	Profile	Searches	`_include`	`_revinclude`	Operations
AllergyIntolerance	Supported profiles: US Core AllergyIntolerance Profile	clinical-status, patient, patient+clinical-status		`Provenance:target`
CarePlan	Supported profiles: CarePlan_eltss	category, date, patient, status, patient+category+status, patient+category+status+date, patient+category, patient+category+date		`Provenance:target`	`$all-eltss-careplan`
CareTeam	Supported profiles: US Core CareTeam Profile	patient, status, role, patient+status, patient+role	`CareTeam:participant:PractitionerRole`, `CareTeam:participant:Practitioner`, `CareTeam:participant:Patient`, `CareTeam:participant:RelatedPerson`	`Provenance:target`
Condition	Supported profiles: US Core Condition Encounter Diagnosis Profile US Core Condition Problems and Health Concerns Profile Condition_eltss	category, clinical-status, patient, onset-date, asserted-date, recorded-date, abatement-date, code, encounter, patient+recorded-date, patient+asserted-date, patient+category+clinical-status, patient+onset-date, patient+abatement-date, patient+clinical-status, patient+category+encounter, patient+code, patient+category		`Provenance:target`
Coverage	Supported profiles: US Core Coverage Profile	patient		`Provenance:target`
Device	Supported profiles: US Core Implantable Device Profile	patient, type, status, patient+type, patient+status		`Provenance:target`
DiagnosticReport	Supported profiles: US Core DiagnosticReport Profile for Report and Note Exchange US Core DiagnosticReport Profile for Laboratory Results Reporting	status, patient, category, code, date, patient+code+date, patient+status, patient+category+date, patient+category, patient+code		`Provenance:target`
DocumentReference	Supported profiles: US Core DocumentReference Profile	_id, status, patient, category, type, date, period, patient+type, patient+status, patient+type+period, patient+category+date, patient+category		`Provenance:target`	`$docref`
Encounter	Supported profiles: US Core Encounter Profile	_id, class, date, identifier, patient, location, status, type, discharge-disposition, patient+type, class+patient, patient+status, date+patient, patient+location, patient+discharge-disposition		`Provenance:target`
Endpoint
Goal	Supported profiles: Goal_eltss	lifecycle-status, patient, target-date, description, patient+target-date, patient+description, patient+lifecycle-status		`Provenance:target`
HealthcareService
Immunization	Supported profiles: US Core Immunization Profile	patient, status, date, patient+date, patient+status		`Provenance:target`
Location	Supported profiles: Location_eltss	name, address, address-city, address-state, address-postalcode
Media
Medication	Supported profiles: US Core Medication Profile
MedicationDispense	Supported profiles: US Core MedicationDispense Profile	status, type, patient, patient+status+type, patient+status	`MedicationDispense:medication`	`Provenance:target`
MedicationRequest	Supported profiles: US Core MedicationRequest Profile	status, intent, patient, encounter, authoredon, patient+intent+encounter, patient+intent+status, patient+intent+authoredon, patient+intent	`MedicationRequest:medication`	`Provenance:target`
Observation	Supported profiles: Observation_eltss US Core Laboratory Result Observation Profile US Core Observation Pregnancy Status Profile US Core Observation Pregnancy Intent Profile US Core Observation Occupation Profile US Core Respiratory Rate Profile US Core Simple Observation Profile US Core Heart Rate Profile US Core Body Temperature Profile US Core Pediatric Weight for Height Observation Profile US Core Pulse Oximetry Profile US Core Smoking Status Observation Profile US Core Observation Sexual Orientation Profile US Core Head Circumference Profile US Core Body Height Profile US Core BMI Profile US Core Observation Screening Assessment Profile US Core Blood Pressure Profile US Core Observation Clinical Result Profile US Core Pediatric BMI for Age Observation Profile US Core Pediatric Head Occipital Frontal Circumference Percentile Profile US Core Body Weight Profile US Core Vital Signs Profile	status, category, code, date, patient, patient+code+date, patient+category+status, patient+category+date, patient+category, patient+code		`Provenance:target`
Organization	Supported profiles: US Core Organization Profile	name, address
Patient	Supported profiles: Patient_eltss	_id, birthdate, death-date, family, gender, given, identifier, name, birthdate+family, family+gender, birthdate+name, gender+name, death-date+family		`Provenance:target`
Practitioner	Supported profiles: Practitioner_eltss	_id, name, identifier
PractitionerRole	Supported profiles: eLTSS PractitionerRole Profile	specialty, practitioner	`PractitionerRole:endpoint`, `PractitionerRole:practitioner`
Procedure	Supported profiles: US Core Procedure Profile	status, patient, date, code, patient+code+date, patient+status, patient+date		`Provenance:target`
Provenance	Supported profiles: US Core Provenance Profile
Questionnaire	Supported profiles: Questionnaire_eltss
QuestionnaireResponse	Supported profiles: eLTSS QuestionnaireResponse Profile	_id, patient, status, authored, questionnaire, patient+questionnaire, patient+authored, patient+status		`Provenance:target`
RelatedPerson	Supported profiles: eLTSS RelatedPerson Profile	_id, patient, name, patient+name		`Provenance:target`
ServiceRequest	Supported profiles: ServiceRequest_eltss	status, patient, category, code, authored, _id, patient+category+authored, patient+status, patient+category, patient+code+authored, patient+code		`Provenance:target`
Specimen	Supported profiles: US Core Specimen Profile	_id, patient
ValueSet					`$expand`

Resource Conformance: SHALLAllergyIntolerance

Core FHIR Resource
AllergyIntolerance

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-allergyintolerance

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	clinical-status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHOULD	patient+clinical-status	`reference`+`token`

Resource Conformance: SHALLCarePlan

Core FHIR Resource
CarePlan

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/CarePlan-eltss

Documentation

Additional considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements:

eLTSS Goal SHOULD be present in CarePlan.goal

eLTSS or US Core Condition SHOULD be present in CarePlan.addresses

Assement and Plan MAY be included as narrative text

Search Parameters

Conformance	Parameter	Type	Documentation
MAY	category	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+category	`reference`+`token`
SHOULD	patient+category+status	`reference`+`token`+`token`
SHOULD	patient+category+status+date	`reference`+`token`+`token`+`date`
SHOULD	patient+category+date	`reference`+`token`+`date`

Extended Operations

Conformance	Operation	Documentation
SHALL	$all-eltss-careplan	A server MAY be capable of responding to a $all-eltss-careplan operation and capable of returning a bundle that provides all eLTSS data for a given Patient’s identified CarePlan. Given a CarePlan with a specific Patient and ID, this operation will return all the referenced artifacts necessary to satisfy the eLTSS data element set found in the DAM. The Operation reduces the number of queries that a client must make. GET [base]/CarePlan/[id]/$all-eltss-careplan

Resource Conformance: SHALLCareTeam

Core FHIR Resource
CareTeam

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-careteam

Documentation

In order to access care team member's names, identifiers, locations, and contact information, the CareTeam profile supports several types of care team participants. They are represented as references to other profiles and include the following four profiles which are marked as must support:

US Core Practitioner Profile

US Core PractitionerRole Profile

US Core Patient Profile

US Core RelatedPerson Profile

Although both US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and _include search parameters), but SHALL support at least one of them.

The client application SHALL support all four profile references.

Bacause the US Core PractitionerRole Profile supplies the provider's location and contact information and a reference to the Practitioner, server systems SHOULD reference it instead of the US Core Practitioner Profile.

Servers that supports only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider's location and contact information using only the Practitioner resource.

Search Parameters

Conformance	Parameter	Type	Documentation
SHOULD	role	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+status	`reference`+`token`
SHOULD	patient+role	`reference`+`token`

Resource Conformance: SHALLCondition

Core FHIR Resource
Condition

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-encounter-diagnosis
http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-problems-health-concerns
http://hl7.org/fhir/us/eltss/StructureDefinition/Condition-eltss

Documentation

For Encounter Diagnosis use the US Core Condition Encounter Diagnosis Profile.

When Condition.category is "encounter-diagnosis" the encounter, SHOULD be referenced in Condition.encounter.

For Problems and Health Concerns use the eLTSSCondition Problems and Health Concerns Profile.

When Condition.category is a "problems-list-item", the `Condition.clinicalStatus SHOULD NOT be unknown.

There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension, Condition.onsetDateTime, or Condition.recordedDate.

Although all three are marked as must support, the server is not required to support all.

A server SHALL support Condition.recordedDate.

A server SHALL support at least one of the assertedDate Extension and Condition.onsetDateTime. A server may support both, which means they support all 3 locations.

The client application SHALL support all three elements.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	category	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	clinical-status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	onset-date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	asserted-date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	recorded-date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	abatement-date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	code	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	encounter	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+category	`reference`+`token`
SHOULD	patient+recorded-date	`reference`+`date`
SHOULD	patient+asserted-date	`reference`+`date`
SHOULD	patient+category+clinical-status	`reference`+`token`+`token`
SHOULD	patient+onset-date	`reference`+`date`
SHOULD	patient+abatement-date	`reference`+`date`
SHOULD	patient+clinical-status	`reference`+`token`
SHOULD	patient+category+encounter	`reference`+`token`+`reference`
SHOULD	patient+code	`reference`+`token`

Resource Conformance: SHALLCoverage

Core FHIR Resource
Coverage

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-coverage

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

Resource Conformance: SHALLDevice

Core FHIR Resource
Device

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device

Documentation

Implantable medical devices that have UDI information SHALL represent the UDI code in Device.udiCarrier.carrierHRF.

All of the five UDI-PI elements that are present in the UDI code SHALL be represented in the corresponding US Core Implantable Device Profile element.

UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants. If UDI is not present and the manufacturer and/or model number information is available, they SHOULD be included to support historical reports of implantable medical devices as follows:

manufacturer -> Device.manufacturer
model -> Device.model

Servers SHOULD support query by Device.type to allow clients to request the patient's devices by a specific type. Note: The Device.type is too granular to differentiate implantable vs. non-implantable devices.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	type	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHOULD	patient+type	`reference`+`token`
SHOULD	patient+status	`reference`+`token`

Resource Conformance: SHALLDiagnosticReport

Core FHIR Resource
DiagnosticReport

Reference Policy
resolves

Interaction summary

SHALL support create, search-type, read.
SHOULD support vread, history-instance.
MAY support update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note
http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-lab

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	category	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	code	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+category+date	`reference`+`token`+`date`
SHALL	patient+category	`reference`+`token`
SHALL	patient+code	`reference`+`token`
SHOULD	patient+code+date	`reference`+`token`+`date`
SHOULD	patient+status	`reference`+`token`

Resource Conformance: SHALLDocumentReference

Core FHIR Resource
DocumentReference

Reference Policy
resolves

Interaction summary

SHALL support create, search-type, read.
SHOULD support vread, history-instance.
MAY support update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference

Documentation

The DocumentReference.type binding SHALL support at a minimum the 5 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set

The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using DocumentReference.attachment.url or the content as inline base64 encoded data using DocumentReference.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.

The client application SHALL support both elements.

The content.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 endpoint is outside the FHIR base URL, it SHOULD NOT require additional authorization to access.

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.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	_id	`token`
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	category	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	type	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	period	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+type	`reference`+`token`
SHALL	patient+category+date	`reference`+`token`+`date`
SHALL	patient+category	`reference`+`token`
SHOULD	patient+status	`reference`+`token`
SHOULD	patient+type+period	`reference`+`token`+`date`

Extended Operations

Conformance	Operation	Documentation
SHALL	$docref	A server SHALL be capable of responding to a $docref operation and capable of returning at least a reference to a generated CCD document, if available. MAY provide references to other 'on-demand' and 'stable' documents (or 'delayed/deferred assembly') that meet the query parameters as well. If a context date range is supplied the server SHOULD provide references to any document that falls within the date range. If no date range is supplied, then the server SHALL provide references to last or current document(s). SHOULD document what resources, if any, are returned as included resources `GET [base]/DocumentReference/$docref?patient=[id]`

Resource Conformance: SHALLEncounter

Core FHIR Resource
Encounter

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-encounter

Documentation

The Encounter resource can represent a reason using either a code with Encounter.reasonCode, or a reference with Encounter.reasonReference to Condition or other resource.

Although both are marked as must support, the server systems 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 or eLTSS Observation if applicable. (for example, a laboratory result should conform to the US Core Laboratory Result Observation Profile)

The location address can be represented by either by the Location referenced by Encounter.location.location or indirectly through the Organization referenced by Encounter.serviceProvider.

Although both are marked as must support, the server systems 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.

if using Encounter.location.location it SHOULD conform to eLTSSLocation.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	_id	`token`
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
SHOULD	identifier	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	class	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	location	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	type	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	discharge-disposition	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	date+patient	`date`+`reference`
SHOULD	patient+type	`reference`+`token`
SHOULD	class+patient	`token`+`reference`
SHOULD	patient+status	`reference`+`token`
SHOULD	patient+location	`reference`+`reference`
SHOULD	patient+discharge-disposition	`reference`+`token`

Resource Conformance: SHALLEndpoint

Core FHIR Resource
Endpoint

Reference Policy
resolves

Interaction summary

SHOULD support read, vread.
MAY support create, search-type, update, patch, delete, history-instance, history-type.

Documentation

The Media Resource is a Must Suppot referenced resource when using the US Core PracitionerRole Profile.

Resource Conformance: SHALLGoal

Core FHIR Resource
Goal

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/Goal-eltss

Documentation

Although both Goal.startDate and Goal.target.dueDate are marked as must support, the server system is not required to support both, but SHALL support at least one of these elements. The client application SHALL support both elements.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	lifecycle-status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	target-date	`date`	A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day.
MAY	description	`token`

Combined Search Parameters

Conformance	Parameters	Types
SHOULD	patient+target-date	`reference`+`date`
SHOULD	patient+description	`reference`+`token`
SHOULD	patient+lifecycle-status	`reference`+`token`

Resource Conformance: MAYHealthcareService

Core FHIR Resource
HealthcareService

Reference Policy
resolves

Interaction summary

SHOULD support read, vread.
MAY support create, search-type, update, patch, delete, history-instance, history-type.

Documentation

The HealthcareService Resource is a referenced resource when using the US Core PracitionRole Profile and subject to constraint us-core-13: "SHALL have a practitioner, an organization, a healthcare service, or a location."

Resource Conformance: SHALLImmunization

Core FHIR Resource
Immunization

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-immunization

Documentation

Based upon the ONC U.S. Core Data for Interoperability (USCDI) requirements, CVX vaccine codes are required and the NDC vaccine codes SHOULD be supported as translations to them.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance	Parameters	Types
SHOULD	patient+date	`reference`+`date`
SHOULD	patient+status	`reference`+`token`

Resource Conformance: SHALLLocation

Core FHIR Resource
Location

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/Location-eltss

Documentation

The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they SHOULD be used as the default profile if referenced by another US Core profile.

Search Parameters

Conformance	Parameter	Type
SHALL	name	`string`
SHALL	address	`string`
SHOULD	address-city	`string`
SHOULD	address-state	`string`
SHOULD	address-postalcode	`string`

Resource Conformance: SHALLMedia

Core FHIR Resource
Media

Reference Policy
resolves

Interaction summary

SHOULD support read, vread.
MAY support create, search-type, update, patch, delete, history-instance, history-type.

Documentation

The Media Resource is a Must Suppot referenced resource when using the US Core DiagnosticReport Profile for Report and Note Exchange.

Resource Conformance: SHALLMedication

Core FHIR Resource
Medication

Reference Policy
resolves

Interaction summary

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-medication

Documentation

The MedicationRequest resource can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationRequest, then the READ SHALL be supported.

Resource Conformance: SHALLMedicationDispense

Core FHIR Resource
MedicationDispense

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-medicationdispense

Documentation

The MedicationDispense resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _include` parameter for searching this element. The client application must support all methods.

For example, A server SHALL be capable of returning dispense records for all medications for a patient using one of or both:

GET /MedicationDispense?patient=[id]

GET /MedicationDispense?patient=[id]&_include=MedicationDispense:medication

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	type	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHOULD	patient+status+type	`reference`+`token`+`token`
SHOULD	patient+status	`reference`+`token`

Resource Conformance: SHALLMedicationRequest

Core FHIR Resource
MedicationRequest

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-medicationrequest

Documentation

The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _include` parameter for searching this element. The client application must support all methods.

For example, A server SHALL be capable of returning all medications for a patient using one of or both:

GET /MedicationRequest?patient=[id]

GET /MedicationRequest?patient=[id]&_include=MedicationRequest:medication

The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or reference in MedicationRequest.reportedBoolean, or a reference using MedicationRequest.reportedReference to Practitioner or other resource.

Although both are marked as must support, the server systems are not required to support both a boolean and a reference, but SHALL choose to support at least one of these elements.

The client application SHALL support both elements.

Search Parameters

Conformance	Parameter	Type	Documentation
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	intent	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	encounter	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	authoredon	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+intent+status	`reference`+`token`+`token`
SHALL	patient+intent	`reference`+`token`
SHOULD	patient+intent+encounter	`reference`+`token`+`reference`
SHOULD	patient+intent+authoredon	`reference`+`token`+`date`

Resource Conformance: SHALLObservation

Core FHIR Resource
Observation

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

Documentation

Systems SHOULD support Observation.effectivePeriod to accurately represent tests that are collected over a period of time (for example, a 24-Hour Urine Collection test).

An Observation without a value, SHALL include a reason why the data is absent unless there are component observations, or references to other Observations that are grouped within it

Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason

An Observation.component without a value, SHALL include a reason why the data is absent.

Systems that never provide an component observation without a component value are not required to support Observation.component.dataAbsentReason.

Systems SHOULD support Observation.effectivePeriod to accurately represent procedure tests that are collected over a period of time.

Search Parameters

Conformance	Parameter	Type	Documentation
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	category	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	code	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+category+date	`reference`+`token`+`date`
SHALL	patient+category	`reference`+`token`
SHALL	patient+code	`reference`+`token`
SHOULD	patient+code+date	`reference`+`token`+`date`
SHOULD	patient+category+status	`reference`+`token`+`token`

Resource Conformance: SHALLOrganization

Core FHIR Resource
Organization

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-organization

Documentation

Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for Organization.Identifier.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	name	`string`
SHALL	address	`string`

Resource Conformance: SHALLPatient

Core FHIR Resource
Patient

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/Patient-eltss

Documentation

For ONC's USCDI requirements, each Patient must support the following additional elements. These elements are included in the formal definition of the profile. The patient examples include all of these elements.

contact detail (e.g. a telephone number or an email address)

a communication language

a race

an ethnicity

a birth sex*

previous name

Previous name is represented by providing an end date in the Patient.name.period element for a previous name.

suffix

Suffix is represented using the Patient.name.suffix element.

The Patient's Social Security Numbers SHOULD NOT be used as a patient identifier in Patient.identifier.value.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	_id	`token`
SHALL	identifier	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
SHALL	name	`string`
MAY	birthdate	`date`	A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day.
MAY	death-date	`date`	A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day.
MAY	family	`string`	A server SHALL support a value precise to the day.
MAY	gender	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	given	`string`

Combined Search Parameters

Conformance	Parameters	Types
SHALL	birthdate+name	`date`+`string`
SHALL	gender+name	`token`+`string`
SHOULD	birthdate+family	`date`+`string`
SHOULD	family+gender	`string`+`token`
SHOULD	death-date+family	`date`+`string`

Resource Conformance: SHALLPractitioner

Core FHIR Resource
Practitioner

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/Practitioner-eltss

Documentation

Servers that support only eLTSSPractitioner Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	name	`string`
SHALL	identifier	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
SHOULD	_id	`token`

Resource Conformance: SHALLPractitionerRole

Core FHIR Resource
PractitionerRole

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/PractitionerRole-eltss

Documentation

The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they SHOULD be used as the default profile if referenced by another US Core profile.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	specialty	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
SHALL	practitioner	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

Resource Conformance: SHALLProcedure

Core FHIR Resource
Procedure

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-procedure

Documentation

Procedure codes can be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT. LOINC.

Only LOINC concepts that reflect actual procedures SHOULD be used

A procedure including an implantable device SHOULD use Procedure.focalDevice with a reference to the US Core Implantable Device Profile.

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	date	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	code	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+date	`reference`+`date`
SHOULD	patient+code+date	`reference`+`token`+`date`
SHOULD	patient+status	`reference`+`token`

Resource Conformance: SHALLProvenance

Core FHIR Resource
Provenance

Reference Policy
resolves

Interaction summary

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-provenance

Documentation

The US Core Provenance resource SHALL be supported for these US Core resources:

AllergyIntolerance

CarePlan

CareTeam

Condition

Coverage

Device

DiagnosticReport

DocumentReference

Encounter

Goal

Immunization

MedicationDispense

MedicationRequest

Observation

Patient

Procedure

QuestionnaireResponse

RelatedPerson

ServiceRequest

If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider.

Systems that need to know the activity has occurred SHOULD populate the activity.

Resource Conformance: SHOULDQuestionnaire

Core FHIR Resource
Questionnaire

Reference Policy

Interaction summary

SHOULD support read, vread.
MAY support create, search-type, update, patch, delete, history-instance, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/Questionnaire-eltss

Documentation

US Core defines two ways to represent the questions and responses to screening and assessment instruments:

Observation: US Core Observation Screening Assessment Profile

Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile

eLTSS/US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile, the eLTSS Questionnaire Profile and the eLTSS QuestionnaireResponse Profile

Resource Conformance: SHOULDQuestionnaireResponse

Core FHIR Resource
QuestionnaireResponse

Reference Policy

Interaction summary

SHOULD support search-type, read, vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/QuestionnaireResponse-eltss

Documentation

US Core defines two ways to represent the questions and responses to screening and assessment instruments:

Observation: US Core Observation Screening Assessment Profile

Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile

eLTSS/US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile , the eLTSS Questionnaire Profile and the eLTSS QuestionnaireResponse Profile

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	_id	`token`
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	authored	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY	questionnaire	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

Combined Search Parameters

Conformance	Parameters	Types
SHOULD	patient+questionnaire	`reference`+`reference`
SHOULD	patient+authored	`reference`+`date`
SHOULD	patient+status	`reference`+`token`

Resource Conformance: SHALLRelatedPerson

Core FHIR Resource
RelatedPerson

Reference Policy
resolves

Interaction summary

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/RelatedPerson-eltss

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	_id	`token`
SHOULD	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
SHOULD	name	`string`

Combined Search Parameters

Conformance	Parameters	Types
SHOULD	patient+name	`reference`+`string`

Resource Conformance: SHALLServiceRequest

Core FHIR Resource
ServiceRequest

Reference Policy
resolves

Interaction summary

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/eltss/StructureDefinition/ServiceRequest-eltss

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	patient	`reference`	The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
SHALL	_id	`token`
MAY	status	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	category	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	code	`token`	The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY	authored	`date`	A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance	Parameters	Types
SHALL	patient+category+authored	`reference`+`token`+`date`
SHALL	patient+category	`reference`+`token`
SHALL	patient+code	`reference`+`token`
SHOULD	patient+status	`reference`+`token`
SHOULD	patient+code+authored	`reference`+`token`+`date`

Resource Conformance: SHALLSpecimen

Core FHIR Resource
Specimen

Reference Policy
resolves

Interaction summary

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-specimen

Search Parameters

Conformance	Parameter	Type	Documentation
SHALL	_id	`token`
SHOULD	patient	`reference`

Resource Conformance: SHOULDValueSet

Core FHIR Resource
ValueSet

Reference Policy

Interaction summary

Extended Operations

Conformance	Operation	Documentation
SHOULD	$expand	If a server supports DocumentReference for creating, using, and sharing clinical notes, it SHOULD also support the `context` and `contextdirection` parameters of the $expand operation to enable clients to determine the supported note and report types, as well as the supported read/write formats for notes on the server.

CapabilityStatement: eLTSS Server

eLTSS Server Capability Statement

SHALL Support the Following Implementation Guides

SHOULD Support the Following Implementation Guides

FHIR RESTful Capabilities

Mode: server

Capabilities by Resource/Profile

Summary

Resource Conformance: SHALLAllergyIntolerance

Resource Conformance: SHALLCarePlan

Resource Conformance: SHALLCareTeam

Resource Conformance: SHALLCondition

Resource Conformance: SHALLCoverage

Resource Conformance: SHALLDevice

Resource Conformance: SHALLDiagnosticReport

Resource Conformance: SHALLDocumentReference

Resource Conformance: SHALLEncounter

Resource Conformance: SHALLEndpoint

Resource Conformance: SHALLGoal

Resource Conformance: MAYHealthcareService

Resource Conformance: SHALLImmunization

Resource Conformance: SHALLLocation

Resource Conformance: SHALLMedia

Resource Conformance: SHALLMedication

Resource Conformance: SHALLMedicationDispense

Resource Conformance: SHALLMedicationRequest

Resource Conformance: SHALLObservation

Resource Conformance: SHALLOrganization

Resource Conformance: SHALLPatient

Resource Conformance: SHALLPractitioner

Resource Conformance: SHALLPractitionerRole

Resource Conformance: SHALLProcedure

Resource Conformance: SHALLProvenance

Resource Conformance: SHOULDQuestionnaire

Resource Conformance: SHOULDQuestionnaireResponse

Resource Conformance: SHALLRelatedPerson

Resource Conformance: SHALLServiceRequest

Resource Conformance: SHALLSpecimen

Resource Conformance: SHOULDValueSet

Mode: `server`