HL7.FHIR.US.SDOH-CLINICALCARE\SDOHCC Referral Recipient Capability Statement

This page is part of the SDOH Clinical Care for Multiple Domains (v2.1.0: STU 2.1) based on FHIR 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: SDOHCC Referral Recipient Capability Statement

Official URL: http://hl7.org/fhir/us/sdoh-clinicalcare/CapabilityStatement/SDOHCC-ReferralRecipient				Version: 2.1.0
Draft as of 2021-06				Computable Name: SDOHCC_ReferralRecipient

This resource describes the required and desired behavior of systems acting as SDOH clinical care ‘referral recipients’. These are typically community-based organizations that can provide services such as food bank access, housing remediation, etc.

In some cases, a referral recipient might actually further refer the patient to a downstream service provider through non-FHIR means. In such cases, the system is still treated as a ‘referral recipient’ rather than a Coordination Platform because, from a FHIR interface perspective, the referral process ‘stops’ with that system. Referral recipients must be able to receive or monitor for Tasks issued by Referral Sources and Coordination Platforms. They must also be able to respond to access the ServiceRequest representing the referral pointed to by the Task and any relevant information referenced by the referral, update the Task with their acceptance or rejection of the referral, and finally provide information about what interventions were actually performed using the Procedure resource.\n\n There are actually two types of referral recipients defined in this implementation guide. This CapabilityStatement describes the expected behavior of more sophisticated service delivery systems that are capable of exposing a FHIR service and persisting Tasks and Procedures in their own environment. A separate set of interface expectations is defined for ‘Light’ Referral Recipients that are not capable of exposing an endpoint and where the Task and any resulting Procedures must be stored in the requesting system’s database.

Raw OpenAPI-Swagger Definition file | Download

SDOHCC Referral Recipient

Official URL:http://hl7.org/fhir/us/sdoh-clinicalcare/CapabilityStatement/SDOHCC-ReferralRecipient
Implementation Guide Version: None
FHIR Version: 4.0.1
Intended Use: Requirements
Supported Formats: XML, JSON
Published: 2021-06
Published by: None
Status: Draft

This resource describes the required and desired behavior of systems acting as SDOH clinical care 'referral recipients'. These are typically community-based organizations that can provide services such as food bank access, housing remediation, etc.

In some cases, a referral recipient might actually further refer the patient to a downstream service provider through non-FHIR means. In such cases, the system is still treated as a 'referral recipient' rather than a Coordination Platform because, from a FHIR interface perspective, the referral process 'stops' with that system. Referral recipients must be able to receive or monitor for Tasks issued by Referral Sources and Coordination Platforms. They must also be able to respond to access the ServiceRequest representing the referral pointed to by the Task and any relevant information referenced by the referral, update the Task with their acceptance or rejection of the referral, and finally provide information about what interventions were actually performed using the Procedure resource.\ There are actually two types of referral recipients defined in this implementation guide. This CapabilityStatement describes the expected behavior of more sophisticated service delivery systems that are capable of exposing a FHIR service and persisting Tasks and Procedures in their own environment. A separate set of interface expectations is defined for 'Light' Referral Recipients that are not capable of exposing an endpoint and where the Task and any resulting Procedures must be stored in the requesting system's database.

FHIR Client RESTful Capabilities

The clinical care referral recipient needs to access information from and update information in SDOH clinical care referral sources and/or coordination platforms that have solicited the filling of SDOH-related referrals by this system

Security:

Implementations must meet the general privacy & security requirements documented in this implementation guide.

Summary of Client Wide Interactions

SHOULD support the batch^† interaction.

batch^†
Allows polling for changes to multiple resource types simultaneously

RESTful Capabilities by Resource/Profile:

Summary

♦ = SHALL expectation;⋄ = SHOULD expectation;▿ = MAY expectation;

Resource Type Supported Interactions Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations

CareTeam read^▿, search-type^▿ US Core CareTeam Profile^♦ _id^♦, _lastUpdated^⋄

Condition read^♦, search-type^⋄ SDOHCC Condition^♦ _id^♦, _lastUpdated^⋄, category^♦, clinical-status^⋄, code^⋄, patient^♦, verification-status^⋄

Consent read^♦, search-type^⋄ SDOHCC Consent^♦ _id^♦, _lastUpdated^⋄, source-reference^♦ Consent:source-reference:DocumentReference^⋄

Device read^⋄, search-type^⋄ FHIR Device^♦ _id^♦, _lastUpdated^⋄

DocumentReference read^♦, search-type^⋄ US Core DocumentReference Profile^♦ _id^♦, _lastUpdated^⋄

Goal read^♦, search-type^⋄ SDOHCC Goal^♦ _id^♦, _lastUpdated^⋄, achievement-status^⋄, category^♦, lifecycle-status^⋄, patient^♦, target-date^⋄

HealthcareService read^⋄, search-type^⋄ SDOHCC Healthcare Service^♦ _id^♦, _lastUpdated^⋄, location^♦

Location read^⋄, search-type^▿ SDOHCC Location^♦ _id^♦, _lastUpdated^⋄

Observation read^♦, search-type^⋄ SDOHCC Observation Assessment^♦, SDOHCC Observation Screening Response^♦, SDOHCC Observation Ethnicity OMB^▿, SDOHCC Observation Race OMB^▿, SDOHCC Observation Gender Identity^▿, SDOHCC Observation Personal Characteristic^▿, SDOHCC Observation Personal Pronouns^▿, SDOHCC Observation Recorded Sex Gender^▿, SDOHCC Observation Sexual Orientation^▿ _id^♦, _lastUpdated^⋄, category^♦, code^⋄, code-value-concept^▿, date^⋄, derived-from^⋄, patient^♦, status^♦

Organization read^♦, search-type^⋄ US Core Organization Profile^♦ _id^♦, _lastUpdated^⋄

Patient read^♦, search-type^⋄ US Core Patient Profile^♦ _id^♦, _lastUpdated^⋄

Practitioner read^♦, search-type^⋄ US Core Practitioner Profile^♦ _id^♦, _lastUpdated^⋄

PractitionerRole read^♦, search-type^⋄ US Core PractitionerRole Profile^♦ _id^♦, _lastUpdated^⋄, organization^⋄, practitioner^⋄ PractitionerRole:organization^⋄, PractitionerRole:practitioner^⋄

Procedure create^♦, update^♦, read^♦, search-type^⋄ SDOHCC Procedure^♦ _id^♦, _lastUpdated^⋄, based-on^♦, category^♦, code^⋄, date^⋄, patient^♦, performer^♦, status^♦

RelatedPerson read^▿, search-type^▿ FHIR RelatedPerson^♦ _id^♦, _lastUpdated^⋄

ServiceRequest read^♦, search-type^⋄ SDOHCC ServiceRequest^♦ _id^♦, _lastUpdated^⋄, category^♦, code^⋄, intent^♦, occurrence^⋄, patient^♦, performer^⋄, requester^⋄, status^♦, supporting-info^⋄ HealthCareService:location^♦, ServiceRequest:supporting-info^⋄, ServiceRequest:pertains-to-goal^⋄, ServiceRequest:patient^⋄, ServiceRequest:requester^⋄, ServiceRequest:performer^⋄, PractitionerRole:practitioner^⋄, PractitionerRole:organization^⋄

Subscription create^⋄, update^▿ R4/B Topic-Based Subscription^♦ $status^⋄, $topic-list^▿

Resource Type	Supported Interactions	Supported Profiles	Supported Searches	Supported `_includes`	Supported Operations
CareTeam	read^▿, search-type^▿	US Core CareTeam Profile^♦	_id^♦, _lastUpdated^⋄
Condition	read^♦, search-type^⋄	SDOHCC Condition^♦	_id^♦, _lastUpdated^⋄, category^♦, clinical-status^⋄, code^⋄, patient^♦, verification-status^⋄
Consent	read^♦, search-type^⋄	SDOHCC Consent^♦	_id^♦, _lastUpdated^⋄, source-reference^♦	Consent:source-reference:DocumentReference^⋄
Device	read^⋄, search-type^⋄	FHIR Device^♦	_id^♦, _lastUpdated^⋄
DocumentReference	read^♦, search-type^⋄	US Core DocumentReference Profile^♦	_id^♦, _lastUpdated^⋄
Goal	read^♦, search-type^⋄	SDOHCC Goal^♦	_id^♦, _lastUpdated^⋄, achievement-status^⋄, category^♦, lifecycle-status^⋄, patient^♦, target-date^⋄
HealthcareService	read^⋄, search-type^⋄	SDOHCC Healthcare Service^♦	_id^♦, _lastUpdated^⋄, location^♦
Location	read^⋄, search-type^▿	SDOHCC Location^♦	_id^♦, _lastUpdated^⋄
Observation	read^♦, search-type^⋄	SDOHCC Observation Assessment^♦, SDOHCC Observation Screening Response^♦, SDOHCC Observation Ethnicity OMB^▿, SDOHCC Observation Race OMB^▿, SDOHCC Observation Gender Identity^▿, SDOHCC Observation Personal Characteristic^▿, SDOHCC Observation Personal Pronouns^▿, SDOHCC Observation Recorded Sex Gender^▿, SDOHCC Observation Sexual Orientation^▿	_id^♦, _lastUpdated^⋄, category^♦, code^⋄, code-value-concept^▿, date^⋄, derived-from^⋄, patient^♦, status^♦
Organization	read^♦, search-type^⋄	US Core Organization Profile^♦	_id^♦, _lastUpdated^⋄
Patient	read^♦, search-type^⋄	US Core Patient Profile^♦	_id^♦, _lastUpdated^⋄
Practitioner	read^♦, search-type^⋄	US Core Practitioner Profile^♦	_id^♦, _lastUpdated^⋄
PractitionerRole	read^♦, search-type^⋄	US Core PractitionerRole Profile^♦	_id^♦, _lastUpdated^⋄, organization^⋄, practitioner^⋄	PractitionerRole:organization^⋄, PractitionerRole:practitioner^⋄
Procedure	create^♦, update^♦, read^♦, search-type^⋄	SDOHCC Procedure^♦	_id^♦, _lastUpdated^⋄, based-on^♦, category^♦, code^⋄, date^⋄, patient^♦, performer^♦, status^♦
RelatedPerson	read^▿, search-type^▿	FHIR RelatedPerson^♦	_id^♦, _lastUpdated^⋄
ServiceRequest	read^♦, search-type^⋄	SDOHCC ServiceRequest^♦	_id^♦, _lastUpdated^⋄, category^♦, code^⋄, intent^♦, occurrence^⋄, patient^♦, performer^⋄, requester^⋄, status^♦, supporting-info^⋄	HealthCareService:location^♦, ServiceRequest:supporting-info^⋄, ServiceRequest:pertains-to-goal^⋄, ServiceRequest:patient^⋄, ServiceRequest:requester^⋄, ServiceRequest:performer^⋄, PractitionerRole:practitioner^⋄, PractitionerRole:organization^⋄
Subscription	create^⋄, update^▿	R4/B Topic-Based Subscription^♦			$status^⋄, $topic-list^▿

CareTeam

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about the intended performer of a ServiceRequest when the performer is a specific team of people. Note: Conformance expectations for this resource are lower because CareTeam performers are expected to be uncommon in most SDOH uses

Supported Profiles:

SHALL support:US Core CareTeam Profile

Reference Policy: literal

Profile Interaction Summary:

MAY support read^†, search-type^†.

read^†
Allows the system to retrieve a CareTeam that is the intended performer of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved CareTeams that are the intended performer of ServiceRequests.

ns.n

Fetch and Search Criteria:

A Client MAY be capable of fetching a CareTeam resource using:GET [base]/CareTeam/[id]
A Client MAY be capable of fetching resources matching a search query using:GET [base]/CareTeam/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/CareTeam?_id=[id]

SHOULD _lastUpdated date GET [base]/CareTeam?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/CareTeam?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/CareTeam?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known CareTeam records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

Condition

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about a patient's SDOH-related conditions, particularly those that are the reason for a referral

Supported Profiles:

SHALL support:SDOHCC Condition

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve a Condition that is the reason for a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved Conditions that are referenced by ServiceRequests.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Condition resource using:GET [base]/Condition/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Condition/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Condition?_id=[id]

SHOULD _lastUpdated date GET [base]/Condition?_lastUpdated=[dateTime]

SHALL category token GET [base]/Condition?category=[system]|[code]

SHOULD clinical-status token GET [base]/Condition?clinical-status=[system]|[code]

SHOULD code token GET [base]/Condition?code=[system]|[code]

SHALL patient reference GET [base]/Condition?patient=[type]/[id]

SHOULD verification-status token GET [base]/Condition?verification-status=[system]|[code]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Condition?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Condition?_lastUpdated=[dateTime]`
SHALL	category	token	`GET [base]/Condition?category=[system]\|[code]`
SHOULD	clinical-status	token	`GET [base]/Condition?clinical-status=[system]\|[code]`
SHOULD	code	token	`GET [base]/Condition?code=[system]\|[code]`
SHALL	patient	reference	`GET [base]/Condition?patient=[type]/[id]`
SHOULD	verification-status	token	`GET [base]/Condition?verification-status=[system]\|[code]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Condition records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
category (token):
Allows filtering to only SDOH-related conditions
clinical-status (token):
Allows filtering to only active conditions
code (token):
Allows filtering to only specific SDOH conditions or sets of conditions
patient (reference):
Allows filtering to only conditions associated with a specific patient. Some systems will require that searches be patient-specific
verification-status (token):
Allows filtering to exclude refuted or entered-in-error conditions

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to access the consent that authorizes disclosure of ServiceRequest information to non-HIPAA-covered entities

Supported Profiles:

SHALL support:SDOHCC Consent

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve a Consent referenced as a 'supportingInformation' item of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved Consents related to ServiceRequests of interest.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Consent resource using:GET [base]/Consent/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Consent/[id]{?[parameters]{&_format=[mime-type]}}
A Client SHOULD be capable of supporting the following _includes:
- Consent:source-reference:DocumentReference - GET [base]/Consent?[parameter=value]&_include=Consent:source-reference:DocumentReference

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Consent?_id=[id]

SHOULD _lastUpdated date GET [base]/Consent?_lastUpdated=[dateTime]

SHALL source-reference reference GET [base]/Consent?source-reference=[type]/[id]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Consent?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Consent?_lastUpdated=[dateTime]`
SHALL	source-reference	reference	`GET [base]/Consent?source-reference=[type]/[id]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known consent records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
source-reference (reference):
Allows including the document that contains the PDF or similar representation of a paper consent

Device

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to retrieve the requester or intended performer of an SDOH ServiceRequest. Note: Conformance expectations for this resource are lower because Device requesters and performers are expected to be uncommon in most SDOH uses

Supported Profiles:

SHALL support:(http://hl7.org/fhir/StructureDefinition/Device)

Reference Policy: literal

Profile Interaction Summary:

SHOULD support read^†, search-type^†.

read^†
Allows the system to retrieve a Device that is the requester or intended performer of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved Devices that are the requester or intended performer of ServiceRequests.

ns.n

Fetch and Search Criteria:

A Client SHOULD be capable of fetching a Device resource using:GET [base]/Device/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Device/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Device?_id=[id]

SHOULD _lastUpdated date GET [base]/Device?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Device?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Device?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Device records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

DocumentReference

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to retrieve a scanned or other form of document representing the text of a consent. Also used for PDF forms.

Supported Profiles:

SHALL support:US Core DocumentReference Profile

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve a PDF or similar content referenced by a Consent or Task.

search-type^†
Allows the monitoring of previously-retrieved DocumentReferences in the event the image/document is amended/corrected/updated.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching a DocumentReference resource using:GET [base]/DocumentReference/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/DocumentReference/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/DocumentReference?_id=[id]

SHOULD _lastUpdated date GET [base]/DocumentReference?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/DocumentReference?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/DocumentReference?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known DocumentReference records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

Goal

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to access goals related to an SDOH referral

Supported Profiles:

SHALL support:SDOHCC Goal

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve a goal referenced by a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved Goals in the event they are updated.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Goal resource using:GET [base]/Goal/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Goal/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Goal?_id=[id]

SHOULD _lastUpdated date GET [base]/Goal?_lastUpdated=[dateTime]

SHOULD achievement-status token GET [base]/Goal?achievement-status=[system]|[code]

SHALL category token GET [base]/Goal?category=[system]|[code]

SHOULD lifecycle-status token GET [base]/Goal?lifecycle-status=[system]|[code]

SHALL patient reference GET [base]/Goal?patient=[type]/[id]

SHOULD target-date date GET [base]/Goal?target-date=[target-date]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Goal?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Goal?_lastUpdated=[dateTime]`
SHOULD	achievement-status	token	`GET [base]/Goal?achievement-status=[system]\|[code]`
SHALL	category	token	`GET [base]/Goal?category=[system]\|[code]`
SHOULD	lifecycle-status	token	`GET [base]/Goal?lifecycle-status=[system]\|[code]`
SHALL	patient	reference	`GET [base]/Goal?patient=[type]/[id]`
SHOULD	target-date	date	`GET [base]/Goal?target-date=[target-date]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Goal records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
achievement-status (token):
Allows filtering to only include unmet goals
category (token):
Allows filtering to only include SDOH-related goals
lifecycle-status (token):
Allows filtering to only include active goals
patient (reference):
Allows filtering to only include goals for a particular patient. Some systems will require searches to be patient-specific
target-date (date):
Allows filtering based on when a particular goal is desired to be achieved

HealthcareService

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about the intended performer of a ServiceRequest when the performer is a specific service within a larger facility. Also used to indicate who a patient or caregiver should contact about a particular service.

Supported Profiles:

SHALL support:SDOHCC Healthcare Service

Reference Policy: literal

Profile Interaction Summary:

SHOULD support read^†, search-type^†.

read^†
Allows the system to retrieve a HealthcareService that is the intended performer of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved HealthcareServices that are the intended performer of ServiceRequests.

ns.n

Fetch and Search Criteria:

A Client SHOULD be capable of fetching a HealthcareService resource using:GET [base]/HealthcareService/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/HealthcareService/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/HealthcareService?_id=[id]

SHOULD _lastUpdated date GET [base]/HealthcareService?_lastUpdated=[dateTime]

SHALL location reference GET [base]/HealthcareService?location=[type]/[id]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/HealthcareService?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/HealthcareService?_lastUpdated=[dateTime]`
SHALL	location	reference	`GET [base]/HealthcareService?location=[type]/[id]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known HealthcareService records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
location (reference):
Allows retrieval of the phyical site(s) associated with a HealthService

Location

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to access information about the potential sites at which a requested service might be performed. Allows a patient to evaluate the suitability of a proposed activity or service.

Supported Profiles:

SHALL support:SDOHCC Location

Reference Policy: literal

Profile Interaction Summary:

SHOULD support read^†.
MAY support search-type^†.

read^†
Allows the system to retrieve a Location that is an available location for a service.

search-type^†
Allows the monitoring of previously-retrieved Locations that are the intended locations for services.

ns.n

Fetch and Search Criteria:

A Client SHOULD be capable of fetching a Location resource using:GET [base]/Location/[id]
A Client MAY be capable of fetching resources matching a search query using:GET [base]/Location/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Location?_id=[id]

SHOULD _lastUpdated date GET [base]/Location?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Location?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Location?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Location records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

Observation

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about SDOH-related observations for a patient - particularly those that are reasons for a referral as well as certain SDOH-relevant demographic information

Supported Profiles:

SHALL support:SDOHCC Observation Assessment,
SHALL support:SDOHCC Observation Screening Response,
MAY support:SDOHCC Observation Ethnicity OMB,
MAY support:SDOHCC Observation Race OMB,
MAY support:SDOHCC Observation Gender Identity,
MAY support:SDOHCC Observation Personal Characteristic,
MAY support:SDOHCC Observation Personal Pronouns,
MAY support:SDOHCC Observation Recorded Sex Gender,
MAY support:SDOHCC Observation Sexual Orientation

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve an Observation referenced by a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved Observations for updates/corrections.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching an Observation resource using:GET [base]/Observation/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Observation/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Observation?_id=[id]

SHOULD _lastUpdated date GET [base]/Observation?_lastUpdated=[dateTime]

SHALL category token GET [base]/Observation?category=[system]|[code]

SHOULD code token GET [base]/Observation?code=[system]|[code]

SHOULD date date GET [base]/Observation?date=[date]

SHOULD derived-from reference GET [base]/Observation?derived-from=[type]/[id]

SHALL patient reference GET [base]/Observation?patient=[type]/[id]

SHALL status token GET [base]/Observation?status=[system]|[code]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Observation?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Observation?_lastUpdated=[dateTime]`
SHALL	category	token	`GET [base]/Observation?category=[system]\|[code]`
SHOULD	code	token	`GET [base]/Observation?code=[system]\|[code]`
SHOULD	date	date	`GET [base]/Observation?date=[date]`
SHOULD	derived-from	reference	`GET [base]/Observation?derived-from=[type]/[id]`
SHALL	patient	reference	`GET [base]/Observation?patient=[type]/[id]`
SHALL	status	token	`GET [base]/Observation?status=[system]\|[code]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Observation records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
category (token):
Allows filtering for only SDOH-related observations
code (token):
Allows filtering for specific types of observations
code-value-concept (composite):
Allows filtering for observations that have a specific coded value answer for a specified observation type
date (date):
Allows filtering for observations that held in a particular time period
derived-from (reference):
Allows filtering for observations derived from a particular QuestionnaireResponse
patient (reference):
Allows filtering for observations specific to a particular patient. Some systems will require that all queries be patient-specific
status (token):
Allows filtering for observations that are completed or revised (i.e. not in-progress or entered-in-error)

Organization

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about an Organization that is the requester or intended performer of a ServiceRequest

Supported Profiles:

SHALL support:US Core Organization Profile

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve an Organization that is the requester or intended performer of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved Organizations that are the requester or intended performer of ServiceRequests.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching an Organization resource using:GET [base]/Organization/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Organization/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Organization?_id=[id]

SHOULD _lastUpdated date GET [base]/Organization?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Organization?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Organization?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Organization records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

Patient

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about the Patient that is the subject a ServiceRequest

Supported Profiles:

SHALL support:US Core Patient Profile

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve the Patient that is the subject of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved Patients.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Patient resource using:GET [base]/Patient/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Patient/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Patient?_id=[id]

SHOULD _lastUpdated date GET [base]/Patient?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Patient?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Patient?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Patient records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

Practitioner

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about an Practitioner that is the requester or intended performer of a ServiceRequest

Supported Profiles:

SHALL support:US Core Practitioner Profile

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve a Practitioner that is the requester or intended performer of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved Practitioners that are the requester or intended performer of ServiceRequests.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Practitioner resource using:GET [base]/Practitioner/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Practitioner/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Practitioner?_id=[id]

SHOULD _lastUpdated date GET [base]/Practitioner?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Practitioner?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Practitioner?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Practitioner records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

PractitionerRole

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about an PractitionerRole that is the requester or intended performer of a ServiceRequest

Supported Profiles:

SHALL support:US Core PractitionerRole Profile

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows the system to retrieve a PractitionerRole that is the requester or intended performer of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved PractitionerRoles that are the requester or intended performer of ServiceRequests.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching a PractitionerRole resource using:GET [base]/PractitionerRole/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/PractitionerRole/[id]{?[parameters]{&_format=[mime-type]}}
A Client SHOULD be capable of supporting the following _includes:
- PractitionerRole:organization - GET [base]/PractitionerRole?[parameter=value]&_include=PractitionerRole:organization
- PractitionerRole:practitioner - GET [base]/PractitionerRole?[parameter=value]&_include=PractitionerRole:practitioner

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/PractitionerRole?_id=[id]

SHOULD _lastUpdated date GET [base]/PractitionerRole?_lastUpdated=[dateTime]

SHOULD organization reference GET [base]/PractitionerRole?organization=[type]/[id]

SHOULD practitioner reference GET [base]/PractitionerRole?practitioner=[type]/[id]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/PractitionerRole?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/PractitionerRole?_lastUpdated=[dateTime]`
SHOULD	organization	reference	`GET [base]/PractitionerRole?organization=[type]/[id]`
SHOULD	practitioner	reference	`GET [base]/PractitionerRole?practitioner=[type]/[id]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known PractitionerRole records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
organization (reference):
Allows doing an _include on Organization when retrieving the PractitionerRole
practitioner (reference):
Allows doing an _include on Practitioner when retrieving the PractitionerRole

Procedure

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to record information about actions that have been performed as a result of a referral

Supported Profiles:

SHALL support:SDOHCC Procedure

Reference Policy: literal

Versioning Policy: versioned-update

Profile Interaction Summary:

SHALL support create^†, update^†, read^†.
SHOULD support search-type^†.

create^†
Allows the system to write records of procedures done in response to a referral on the system that asked for the referral.

update^†
Allows the system to update records of procedures done in response to a referral on the system that asked for the referral.

read^†
Allows the referral recipient to retrieve procedures referenced by Tasks previously posted.

search-type^†
Allows the referral recipient to check if others have updated (e.g. added comments) to procedures previously posted and/or to find previously submitted procedures so they can be rendered to a user.

ns.n

Modify Criteria:

A Client SHALL be capable of posting a Procedure resource using:POST [base]/Procedure/[id]{?_format=[mime-type]}
A Client SHALL be capable of putting an existing Procedure resource using:PUT [base]/Procedure/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Procedure resource using:GET [base]/Procedure/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/Procedure/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Procedure?_id=[id]

SHOULD _lastUpdated date GET [base]/Procedure?_lastUpdated=[dateTime]

SHALL based-on reference GET [base]/Procedure?based-on=[type]/[id]

SHALL category token GET [base]/Procedure?category=[system]|[code]

SHOULD code token GET [base]/Procedure?code=[system]|[code]

SHOULD date date GET [base]/Procedure?date=[date]

SHALL patient reference GET [base]/Procedure?patient=[type]/[id]

SHALL performer reference GET [base]/Procedure?performer=[type]/[id]

SHALL status token GET [base]/Procedure?status=[system]|[code]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Procedure?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Procedure?_lastUpdated=[dateTime]`
SHALL	based-on	reference	`GET [base]/Procedure?based-on=[type]/[id]`
SHALL	category	token	`GET [base]/Procedure?category=[system]\|[code]`
SHOULD	code	token	`GET [base]/Procedure?code=[system]\|[code]`
SHOULD	date	date	`GET [base]/Procedure?date=[date]`
SHALL	patient	reference	`GET [base]/Procedure?patient=[type]/[id]`
SHALL	performer	reference	`GET [base]/Procedure?performer=[type]/[id]`
SHALL	status	token	`GET [base]/Procedure?status=[system]\|[code]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Procedure records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
based-on (reference):
Allows filtering for procedures resulting from a particular service request
category (token):
Allows filtering for procedures that are SDOH-related
code (token):
Allows filtering for procedures based on the specific service delivered
date (date):
Allows filtering for procedures based on when they were delivered
patient (reference):
Allows filtering for procedures based on who they were delivered to. Some systems may require that all searches be patient-specific.
performer (reference):
Allows filtering for procedures based on who delivered the procedure.
status (token):
Allows filtering for procedures that are complete or in progress

RelatedPerson

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to access information about the requester or intended performer of a ServiceRequest when they are someone with a personal relationship to the Patient. Note: Conformance expectations for this resource are lower because CareTeam performers are expected to be uncommon in most SDOH uses

Supported Profiles:

SHALL support:(http://hl7.org/fhir/StructureDefinition/RelatedPerson)

Reference Policy: literal

Profile Interaction Summary:

MAY support read^†, search-type^†.

read^†
Allows the system to retrieve a RelatedPerson that is the requester or intended performer of a ServiceRequest.

search-type^†
Allows the monitoring of previously-retrieved RelatedPersons that are the requester or intended performer of ServiceRequests.

ns.n

Fetch and Search Criteria:

A Client MAY be capable of fetching a RelatedPerson resource using:GET [base]/RelatedPerson/[id]
A Client MAY be capable of fetching resources matching a search query using:GET [base]/RelatedPerson/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/RelatedPerson?_id=[id]

SHOULD _lastUpdated date GET [base]/RelatedPerson?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/RelatedPerson?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/RelatedPerson?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known RelatedPerson records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

ServiceRequest

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

For referral sources that receive referrals from upstream systems, used to retrieve an order for SDOH-related services

Supported Profiles:

SHALL support:SDOHCC ServiceRequest

Reference Policy: literal

Profile Interaction Summary:

SHALL support read^†.
SHOULD support search-type^†.

read^†
Allows client systems to retrieve the ServiceRequest pointed to by a Task.

search-type^†
Allows client systems to monitor multiple ServiceRequests for change simultaneously via polling.

ns.n

Fetch and Search Criteria:

A Client SHALL be capable of fetching a ServiceRequest resource using:GET [base]/ServiceRequest/[id]
A Client SHOULD be capable of fetching resources matching a search query using:GET [base]/ServiceRequest/[id]{?[parameters]{&_format=[mime-type]}}
A Client SHALL be capable of supporting the following _includes:
- HealthCareService:location - GET [base]/ServiceRequest?[parameter=value]&_include=HealthCareService:location
- ServiceRequest:supporting-info - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest:supporting-info
- ServiceRequest:pertains-to-goal - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest:pertains-to-goal
- ServiceRequest:patient - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest:patient
- ServiceRequest:requester - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest:requester
- ServiceRequest:performer - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest:performer
- PractitionerRole:practitioner - GET [base]/ServiceRequest?[parameter=value]&_include=PractitionerRole:practitioner
- PractitionerRole:organization - GET [base]/ServiceRequest?[parameter=value]&_include=PractitionerRole:organization

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/ServiceRequest?_id=[id]

SHOULD _lastUpdated date GET [base]/ServiceRequest?_lastUpdated=[dateTime]

SHALL category token GET [base]/ServiceRequest?category=[system]|[code]

SHOULD code token GET [base]/ServiceRequest?code=[system]|[code]

SHALL intent token GET [base]/ServiceRequest?intent=[system]|[code]

SHOULD occurrence date GET [base]/ServiceRequest?occurrence=[occurrence]

SHALL patient reference GET [base]/ServiceRequest?patient=[type]/[id]

SHOULD performer reference GET [base]/ServiceRequest?performer=[type]/[id]

SHOULD requester reference GET [base]/ServiceRequest?requester=[type]/[id]

SHALL status token GET [base]/ServiceRequest?status=[system]|[code]

SHOULD supporting-info reference GET [base]/ServiceRequest?supporting-info=[type]/[id]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/ServiceRequest?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/ServiceRequest?_lastUpdated=[dateTime]`
SHALL	category	token	`GET [base]/ServiceRequest?category=[system]\|[code]`
SHOULD	code	token	`GET [base]/ServiceRequest?code=[system]\|[code]`
SHALL	intent	token	`GET [base]/ServiceRequest?intent=[system]\|[code]`
SHOULD	occurrence	date	`GET [base]/ServiceRequest?occurrence=[occurrence]`
SHALL	patient	reference	`GET [base]/ServiceRequest?patient=[type]/[id]`
SHOULD	performer	reference	`GET [base]/ServiceRequest?performer=[type]/[id]`
SHOULD	requester	reference	`GET [base]/ServiceRequest?requester=[type]/[id]`
SHALL	status	token	`GET [base]/ServiceRequest?status=[system]\|[code]`
SHOULD	supporting-info	reference	`GET [base]/ServiceRequest?supporting-info=[type]/[id]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known ServiceRequests records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
category (token):
Allows filtering to only retrieve ServiceRequests that are SDOH-related
code (token):
Allows filtering to retrieve ServiceRequests for specific types of services
intent (token):
Allows filtering to retrieve only 'order' ServiceRequests and not plans, proposals, etc.
occurrence (date):
Allows filtering to retrieve ServiceRequests based on the timeframe in which the service needs to be provided
patient (reference):
Allows filtering to retrieve only ServiceRequests associated with a particular patient. Note that some systems may mandate that searches are always patient-specific
performer (reference):
Allows filtering to retrieve only ServiceRequests that designate a specific performer
requester (reference):
Allows filtering to retrieve only ServiceRequests created by a specific practitioner
status (token):
Allows filtering to retrieve only active ServiceRequests
supporting-info (reference):
Allows _include to retrieve supporting information for a ServiceRequest - particularly Consent

Subscription

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to allow upstream systems to subscribe to and monitor Tasks stored on this system for change

Supported Profiles:

SHALL support:R4/B Topic-Based Subscription

Profile Interaction Summary:

SHOULD support create^†.
MAY support update^†.

create^†
Necessary if using subscriptions to monitor updates to the Task

update^†
Needed to allow the requester to update a subscription - to adjust delivery target, to add additional tasks to monitor (if subscribing by id) typically to cancel a request for fulfillment

Operation Summary:

SHOULD support $status^†.
MAY support $topic-list^†.

$status^†
Necessary for systems supporting subscriptions to ensure that the subscription is functioning properly and to check for errors

$topic-list^†
Allows discovery of what subscription topics the systems supports - needed for systems that aren't pre-configured to be aware of what topics are available for use.

ns.n

Modify Criteria:

A Client SHOULD be capable of posting a Subscription resource using:POST [base]/Subscription/[id]{?_format=[mime-type]}
A Client MAY be capable of putting an existing Subscription resource using:PUT [base]/Subscription/[id]{?_format=[mime-type]}

FHIR Server RESTful Capabilities

The clinical care referral recipient needs to allow SDOH clinical care referral sources and coordination platforms to have solicited the filling of SDOH-related referrals by this system and also to access Procedures that describe interventions taken by the users of this system.

Security:

Implementations must meet the general privacy & security requirements documented in this implementation guide.

Summary of Server Wide Interactions

SHOULD support the batch^† interaction.

batch^†
Allows other systems to poll for changes to multiple resource types simultaneously

RESTful Capabilities by Resource/Profile:

Summary

♦ = SHALL expectation;⋄ = SHOULD expectation;▿ = MAY expectation;

Resource Type Supported Interactions Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations

DocumentReference create^♦, update^⋄, read^♦, search-type^♦ US Core DocumentReference Profile^♦ _id^♦, _lastUpdated^⋄

Subscription create^⋄, update^▿ R4/B Topic-Based Subscription^♦ $status^⋄, $topic-list^▿

Task create^♦, update^♦, read^♦, search-type^♦ SDOHCC Task For Patient^♦, SDOHCC Task For Referral Management^♦ _id^♦, _lastUpdated^⋄, code^♦, owner^⋄, patient^♦, requester^♦, status^♦, focus^♦, output^⋄ Task:output

Resource Type	Supported Interactions	Supported Profiles	Supported Searches	Supported `_includes`	Supported Operations
DocumentReference	create^♦, update^⋄, read^♦, search-type^♦	US Core DocumentReference Profile^♦	_id^♦, _lastUpdated^⋄
Subscription	create^⋄, update^▿	R4/B Topic-Based Subscription^♦			$status^⋄, $topic-list^▿
Task	create^♦, update^♦, read^♦, search-type^♦	SDOHCC Task For Patient^♦, SDOHCC Task For Referral Management^♦	_id^♦, _lastUpdated^⋄, code^♦, owner^⋄, patient^♦, requester^♦, status^♦, focus^♦, output^⋄	Task:output

DocumentReference

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used convey a scanned or other form of document representing the text of a consent. Also used for PDF forms.

Supported Profiles:

SHALL support:US Core DocumentReference Profile

Reference Policy: literal

Profile Interaction Summary:

SHALL support create^†, read^†, search-type^†.
SHOULD support update^†.

create^†
Allows the app to record a new PDF (e.g. a completed form)

update^†
Allows the system to revise a previously stored PDF

read^†
Allows patient apps to retrieve a PDF or similar content referenced by a Consent or Task.

search-type^†
Allows patient apps to monitor previously-retrieved DocumentReferences in the event the image/document is amended/corrected/updated.

ns.n

Modify Criteria:

A Server SHALL be capable of creating a DocumentReference resource using:POST [base]/DocumentReference/[id]{?_format=[mime-type]}
A Server SHOULD be capable of updating an existing DocumentReference resource using:PUT [base]/DocumentReference/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

A Server SHALL be capable of returning a DocumentReference resource using:GET [base]/DocumentReference/[id]
A Server SHALL be capable of returning resources matching a search query using:GET [base]/DocumentReference/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/DocumentReference?_id=[id]

SHOULD _lastUpdated date GET [base]/DocumentReference?_lastUpdated=[dateTime]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/DocumentReference?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/DocumentReference?_lastUpdated=[dateTime]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known DocumentReference records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query

Subscription

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to allow upstream coordination platforms and referral sources to subscribe to and monitor Tasks created on this system

Supported Profiles:

SHALL support:R4/B Topic-Based Subscription

Profile Interaction Summary:

SHOULD support create^†.
MAY support update^†.

create^†
Allows upstream systems to initiate a subscription to monitor updates to Tasks (and theoretically other things)

update^†
Allows upstream systems to revise existing subscriptions - to adjust delivery target, to add additional tasks to monitor (if subscribing by id), etc.

Operation Summary:

SHOULD support $status^†.
MAY support $topic-list^†.

$status^†
Allows upstream systems to verify their subscription is functioning properly and to check for errors

$topic-list^†
Allows upstream systems to discover of what subscription topics this system supports - needed for systems that aren't pre-configured to be aware of what topics are available for use.

ns.n

Modify Criteria:

A Server SHOULD be capable of creating a Subscription resource using:POST [base]/Subscription/[id]{?_format=[mime-type]}
A Server MAY be capable of updating an existing Subscription resource using:PUT [base]/Subscription/[id]{?_format=[mime-type]}

Task

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used by upstream referral sources and coordination platforms to create and update Tasks seeking fufillment of ServiceRequests. Also used by downstream referral recipiencts to monitor and update Tasks stored on this system as they respond to requests to fulfill referrals and link in information about actions taken so far

Supported Profiles:

SHALL support:SDOHCC Task For Patient,
SHALL support:SDOHCC Task For Referral Management

Reference Policy: literal

Versioning Policy: versioned-update

Profile Interaction Summary:

SHALL support create^†, update^†, read^†, search-type^†.

create^†
Allows upstream coordination platforms and referral sources system to create tasks on this system seeking fulfillment of a ServiceRequest or requesting that a patient or caregiver perform certain activities.

update^†
Allows modification of an existing Task by upstream systems (e.g. to cancel it) or by downstream systems (to accept or reject it or add output links to performed procedures). ReferralRecipients can freely modify any Tasks they have created (though they should consider the impact of doing so on downstream recipients or the patient). However, if they are not the creator, they SHALL only modify tasks they are the 'owner' of and then, only modify Task.status, Task.statusReason, and Task.outputs are possible, and then only for Tasks where the owner is the patient.

read^†
Allows retrieval of a Task that was referenced in a subscription notification or per-Task polling for change.

search-type^†
Allows the other systems to poll multiple tasks simultaneously, as well as to retrieve referenced resources as part of a single query.

ns.n

Modify Criteria:

A Server SHALL be capable of creating a Task resource using:POST [base]/Task/[id]{?_format=[mime-type]}
A Server SHALL be capable of updating an existing Task resource using:PUT [base]/Task/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

A Server SHALL be capable of returning a Task resource using:GET [base]/Task/[id]
- A Server (conformance expectation undefined) support conditional read of Task resources only with the If-Modified-Since HTTP Header.
A Server SHALL be capable of returning resources matching a search query using:GET [base]/Task/[id]{?[parameters]{&_format=[mime-type]}}
A Server (conformance expectation undefined) be capable of supporting the following _includes:
- Task:output - GET [base]/Task?[parameter=value]&_include=Task:output

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Task?_id=[id]

SHOULD _lastUpdated date GET [base]/Task?_lastUpdated=[dateTime]

SHALL code token GET [base]/Task?code=[system]|[code]

SHOULD owner reference GET [base]/Task?owner=[type]/[id]

SHALL patient reference GET [base]/Task?patient=[type]/[id]

SHALL requester reference GET [base]/Task?requester=[type]/[id]

SHALL status token GET [base]/Task?status=[system]|[code]

SHALL focus reference GET [base]/Task?focus=[type]/[id]

SHOULD output reference GET [base]/Task?output=[type]/[id]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Task?_id=[id]`
SHOULD	_lastUpdated	date	`GET [base]/Task?_lastUpdated=[dateTime]`
SHALL	code	token	`GET [base]/Task?code=[system]\|[code]`
SHOULD	owner	reference	`GET [base]/Task?owner=[type]/[id]`
SHALL	patient	reference	`GET [base]/Task?patient=[type]/[id]`
SHALL	requester	reference	`GET [base]/Task?requester=[type]/[id]`
SHALL	status	token	`GET [base]/Task?status=[system]\|[code]`
SHALL	focus	reference	`GET [base]/Task?focus=[type]/[id]`
SHOULD	output	reference	`GET [base]/Task?output=[type]/[id]`

Search Parameter Requirements (When Used Alone or in Combination):

_id (token):
Allows retrieving known Task records - and more specifically, retrieving more than one in a single call to poll for updates
_lastUpdated (date):
Allows filtering for only records that have changed since last query
code (token):
Allows filtering for 'fulfill' tasks as opposed to others. Some systems may require code to be included as a filter criteria as different Task codes may correspond to different internal database tables.
owner (reference):
Allows filtering only for tasks that are assigned to a particular owner (or alternatively, tasks that have not yet been assigned)
patient (reference):
Allows monitoring of tasks associated with a particular patient. (Some systems may require that all queries be done in the context of a single patient.)
requester (reference):
Allows retrieving all tasks that have been requested by a particular organization or individual. This will commonly be used to monitor the tasks initiated by a particular system
status (token):
Allows filtering to only active or completed tasks
focus (reference):
Allows retrieving the task(s) seeking fulfillment of a particular ServiceRequest
output (reference):
Allows for the 'output' of a Task to be included when retrieving a Task