SDOH Clinical Care
2.1.0 - STU 2.1 United States of America flag

SDOH Clinical Care, published by HL7 International / Patient Care. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-sdoh-clinicalcare/ and changes regularly. See the Directory of published versions

CapabilityStatement: SDOHCC Patient Application

Official URL: http://hl7.org/fhir/us/sdoh-clinicalcare/CapabilityStatement/SDOHCC-PatientApp Version: 2.1.0
Standards status: Trial-use Computable Name: SDOHCC_PatientApp

This resource describes the required and desired behavior of systems acting as apps for patients and care-givers who need to monitor progress on SDOH referrals and may need to take actions such as filling out forms, booking appointments, etc.

These systems will not expose their own FHIR interfaces, but will monitor information available from other FHIR servers - be it referral sources, coordination platforms or referral recipients. They will primarily monitor and update Task resources as well as the resources referenced by those Tasks.

Raw OpenAPI-Swagger Definition file | Download

SDOHCC Patient Application

  • Official URL:http://hl7.org/fhir/us/sdoh-clinicalcare/CapabilityStatement/SDOHCC-PatientApp
  • 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 apps for patients and care-givers who need to monitor progress on SDOH referrals and may need to take actions such as filling out forms, booking appointments, etc.

These systems will not expose their own FHIR interfaces, but will monitor information available from other FHIR servers - be it referral sources, coordination platforms or referral recipients. They will primarily monitor and update Task resources as well as the resources referenced by those Tasks.

FHIR Client RESTful Capabilities

Patient apps query for data relevant to the current patient, post updates as appropriate and occasionally create new resources, such as QuestionnaireResponses

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 TypeSupported InteractionsSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
CareTeamread, search-type US Core CareTeam Profile _id, _lastUpdated
Conditionread, search-type SDOHCC Condition _id, _lastUpdated, category, clinical-status, code, patient, verification-status
Observationread, search-type SDOHCC Observation Assessment, SDOHCC Observation Screening Response _id, _lastUpdated, category, code, patient
Consentread, search-type SDOHCC Consent _id, _lastUpdated, source-reference Consent:source-reference:DocumentReference
Deviceread, search-type FHIR Device _id, _lastUpdated
DocumentReferencecreate, update, read, search-type US Core DocumentReference Profile _id, _lastUpdated
Goalread, search-type SDOHCC Goal _id, _lastUpdated, achievement-status, category, lifecycle-status, patient, target-date
HealthcareServiceread, search-type SDOHCC Healthcare Service _id, _lastUpdated, location
Locationread, search-type SDOHCC Location _id, _lastUpdated
Practitionerread, search-type US Core Practitioner Profile _id, _lastUpdated
PractitionerRoleread, search-type US Core PractitionerRole Profile _id, _lastUpdated, organization, practitioner PractitionerRole:organization, PractitionerRole:practitioner
Questionnairesearch-type Extractable Questionnaire - StructureMap url, version $populate
QuestionnaireResponsecreate, update, read, search-type SDC Questionnaire Response _id, _lastUpdated, author, authored, patient, questionnaire, status
RelatedPersonread, search-type FHIR RelatedPerson _id, _lastUpdated
ServiceRequestread, 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
Taskupdate, read, search-type SDOHCC Task For Patient, SDOHCC Task For Referral Management _id, _lastUpdated, code, owner, patient, requester, status, focus, output Task:output

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:

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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/CareTeam?_id=[id]
SHOULD_lastUpdateddateGET [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:

Reference Policy: literal

Profile Interaction Summary:

  • SHOULD support read, search-type.

read

Allows the system to retrieve a Condition that is the requester or performer of a ServiceRequest.

search-type

Allows the monitoring of previously-retrieved Conditions that are referenced by ServiceRequests.

ns.n

Fetch and Search Criteria:

  • A Client SHOULD 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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Condition?_id=[id]
SHOULD_lastUpdateddateGET [base]/Condition?_lastUpdated=[dateTime]
SHALLcategorytokenGET [base]/Condition?category=[system]|[code]
SHOULDclinical-statustokenGET [base]/Condition?clinical-status=[system]|[code]
SHOULDcodetokenGET [base]/Condition?code=[system]|[code]
SHALLpatientreferenceGET [base]/Condition?patient=[type]/[id]
SHOULDverification-statustokenGET [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

Observation

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Allows patients and caregivers to see observations recorded by their care providers, including those referenced by other resources

Supported Profiles:

Reference Policy: literal

Profile Interaction Summary:

  • SHALL support read, search-type.

read

Allows the system to retrieve an Observation referenced by a ServiceRequest or other resource.

search-type

Allows the retrieval of Observations recorded about a patient and/or monitoring of previously-retrieved Observations (though typically, they won't change once recorded).

ns.n

Fetch and Search Criteria:

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

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Observation?_id=[id]
SHOULD_lastUpdateddateGET [base]/Observation?_lastUpdated=[dateTime]
SHALLcategorytokenGET [base]/Observation?category=[system]|[code]
SHOULDcodetokenGET [base]/Observation?code=[system]|[code]
SHALLpatientreferenceGET [base]/Observation?patient=[type]/[id]

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 been created or changed since last query

  • category (token):

    Allows filtering to only SDOH-related observations

  • code (token):

    Allows filtering to only specific SDOH observation types

  • patient (reference):

    Allows filtering to only conditions associated with a specific patient. Some systems will require that searches be patient-specific

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:

Reference Policy: literal

Profile Interaction Summary:

  • SHOULD support read, 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 SHOULD 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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Consent?_id=[id]
SHOULD_lastUpdateddateGET [base]/Consent?_lastUpdated=[dateTime]
SHOULDsource-referencereferenceGET [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:

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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Device?_id=[id]
SHOULD_lastUpdateddateGET [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:

Reference Policy: literal

Profile Interaction Summary:

  • SHALL support create, read.
  • SHOULD support update, search-type.

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

Modify Criteria:

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

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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/DocumentReference?_id=[id]
SHOULD_lastUpdateddateGET [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:

Reference Policy: literal

Profile Interaction Summary:

  • SHOULD support read, 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 SHOULD 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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Goal?_id=[id]
SHOULD_lastUpdateddateGET [base]/Goal?_lastUpdated=[dateTime]
SHOULDachievement-statustokenGET [base]/Goal?achievement-status=[system]|[code]
SHALLcategorytokenGET [base]/Goal?category=[system]|[code]
SHOULDlifecycle-statustokenGET [base]/Goal?lifecycle-status=[system]|[code]
SHALLpatientreferenceGET [base]/Goal?patient=[type]/[id]
SHOULDtarget-datedateGET [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:

Allows patient apps to retrieve information about who should be contacted (to book an appointment or for other reasons)

Supported Profiles:

Reference Policy: literal

Profile Interaction Summary:

  • SHALL support read.
  • MAY support search-type.

read

Allows the system to retrieve a HealthcareService referenced by a Task.

search-type

Allows the monitoring of previously-retrieved HealthcareServices.

ns.n

Fetch and Search Criteria:

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

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/HealthcareService?_id=[id]
SHOULD_lastUpdateddateGET [base]/HealthcareService?_lastUpdated=[dateTime]
SHALLlocationreferenceGET [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:

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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Location?_id=[id]
SHOULD_lastUpdateddateGET [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

Practitioner

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to access information about an Practitioner that is the requester or intended performer of a ServiceRequest

Supported Profiles:

Reference Policy: literal

Profile Interaction Summary:

  • SHOULD support read, 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 SHOULD 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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Practitioner?_id=[id]
SHOULD_lastUpdateddateGET [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:

Used to access information about an PractitionerRole that is the requester or intended performer of a ServiceRequest

Supported Profiles:

Reference Policy: literal

Profile Interaction Summary:

  • SHOULD support read, 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 SHOULD 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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/PractitionerRole?_id=[id]
SHOULD_lastUpdateddateGET [base]/PractitionerRole?_lastUpdated=[dateTime]
SHOULDorganizationreferenceGET [base]/PractitionerRole?organization=[type]/[id]
SHOULDpractitionerreferenceGET [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

Questionnaire

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to retrieve SDOH-related Questionnaires to be filled out by a patient or representative. Also allows retrieving Questionnaires associated with existing QuestionnaireResponses for editing by SMART-on-FHIR apps.

Supported Profiles:

Reference Policy: literal

Profile Interaction Summary:

  • SHALL support search-type.

search-type

Allows the referral source to search for questionnaires relevant to a patient context.

Operation Summary:

  • MAY support $populate.

$populate

Allows SMART on FHIR or other systems to pre-populate a questionnaire response with existing information either available locally or queried from elsewhere

ns.n

Fetch and Search Criteria:

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

Search Parameter Summary:

ConformanceParameterTypeExample
SHALLurluriGET [base]/Questionnaire?url=[uri]
SHALLversiontokenGET [base]/Questionnaire?version=[system]|[code]

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

  • url (uri):

    Allows retrieving Questionnaires based on its canonical URL

  • version (token):

    Allows retrieving a specific version of a Questionnaire

QuestionnaireResponse

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to allow QuestionnaireResponses to be created and updated by a patient or caregiver and work-in-progress responses to be retrieved

Supported Profiles:

Reference Policy: literal

Profile Interaction Summary:

  • SHALL support create, read.
  • SHOULD support update, search-type.

create

Allows the creation of QuestionnaireResponses in response to Tasks.

update

Allows the revision of 'in progress' QuestionnaireResponses.

read

Allows the retrieval of QuestionnaireResponses linked to a pointed to as supporting information by a ServiceRequest or as outputs of a Task.

search-type

Allows checking for updates in previously retrieved QuestionnaireResponses.

ns.n

Modify Criteria:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/QuestionnaireResponse?_id=[id]
SHOULD_lastUpdateddateGET [base]/QuestionnaireResponse?_lastUpdated=[dateTime]
SHALLauthorreferenceGET [base]/QuestionnaireResponse?author=[type]/[id]
SHOULDauthoreddateGET [base]/QuestionnaireResponse?authored=[authored]
SHALLpatientreferenceGET [base]/QuestionnaireResponse?patient=[type]/[id]
SHALLquestionnairereferenceGET [base]/QuestionnaireResponse?questionnaire=[type]/[id]
SHALLstatustokenGET [base]/QuestionnaireResponse?status=[system]|[code]

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

  • _id (token):

    Allows retrieving known QuestionnaireResponse 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

  • author (reference):

    Allows filtering QuestionnaireResponses previously created/edited by a particular individual

  • authored (date):

    Allows filtering for QuestionnaireResponses by when they were created/last edited

  • patient (reference):

    Allows retrieving QuestionnaireResponses associated with a particular patient. Some systems may only permit searches that are patient-specific

  • questionnaire (reference):

    Allows retrieving QuestionnaireResponses that have been completed against a specified form

  • status (token):

    Allows retrieving QuestionnaireResponses that are complete (or incomplete)

RelatedPerson

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Used to access information about the requester or intended performer of a ServiceRequest or Task 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:

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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/RelatedPerson?_id=[id]
SHOULD_lastUpdateddateGET [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:

Reference Policy: literal

Profile Interaction Summary:

  • SHOULD support read, 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 SHOULD 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:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/ServiceRequest?_id=[id]
SHOULD_lastUpdateddateGET [base]/ServiceRequest?_lastUpdated=[dateTime]
SHALLcategorytokenGET [base]/ServiceRequest?category=[system]|[code]
SHOULDcodetokenGET [base]/ServiceRequest?code=[system]|[code]
SHALLintenttokenGET [base]/ServiceRequest?intent=[system]|[code]
SHOULDoccurrencedateGET [base]/ServiceRequest?occurrence=[occurrence]
SHALLpatientreferenceGET [base]/ServiceRequest?patient=[type]/[id]
SHOULDperformerreferenceGET [base]/ServiceRequest?performer=[type]/[id]
SHOULDrequesterreferenceGET [base]/ServiceRequest?requester=[type]/[id]
SHALLstatustokenGET [base]/ServiceRequest?status=[system]|[code]
SHOULDsupporting-inforeferenceGET [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

Task

Conformance Expectation:(conformance expectation undefined)

Resource Specific Documentation:

Allows the patient or caregiver to monitor and update for Task assigned by referral sources or coordination platforms. Also allows the update and monitoring of tasks assigned to patients and caregivers.

Supported Profiles:

Reference Policy: literal

Versioning Policy: versioned-update

Profile Interaction Summary:

  • SHALL support update, search-type.
  • MAY support read.

update

Allows modification of an assigned patient existing Task (e.g. to cancel it) or modificiation of a Task assigned to the referral recipient (to accept or reject it or add output links to performed procedures). Systems SHALL ensure that only changes to 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 previously accessed.

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 Client SHALL be capable of putting an existing Task resource using:PUT [base]/Task/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

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

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Task?_id=[id]
SHOULD_lastUpdateddateGET [base]/Task?_lastUpdated=[dateTime]
SHALLcodetokenGET [base]/Task?code=[system]|[code]
SHOULDownerreferenceGET [base]/Task?owner=[type]/[id]
SHALLpatientreferenceGET [base]/Task?patient=[type]/[id]
SHALLrequesterreferenceGET [base]/Task?requester=[type]/[id]
SHALLstatustokenGET [base]/Task?status=[system]|[code]
SHALLfocusreferenceGET [base]/Task?focus=[type]/[id]
SHOULDoutputreferenceGET [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