PACIO Personal Functioning and Engagement Servers SHALL support the capabilities described in the US Core Server CapabilityStatement.

These collection observations represent structured instruments and panels with multiple questions. The hasMember element SHALL be used to point to child Observation instances that contain the specific questions and answers, represented by Single Observations or nested panels represented by this profile.

The Observation.value and Observation.component elements SHALL be empty.

When a health or health-related domain is specified as an additional category value, Observation.code SHOULD be drawn from the corresponding domain-based value set as discussed below and on the domains page.

SHALL support searching using the combination of the patient and category search parameters:

SHALL support searching using the combination of the patient and code search parameters:

SHOULD support search by multiple report codes.

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

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

SHOULD support searching using the combination of the patient and code and date search parameters:

SHOULD support search by multiple report codes.

Implementations SHALL follow the US Core Device Profile UDI Specific Implementation Guidance when exchanging Unique Device Identifier (UDI) information.

FHIR R4 DeviceRequest.requester allows Device, Practitioner, PractitionerRole, and Organization. FHIR R6 DeviceRequest.requester also allows CareTeam, Group, Patient, and RelatedPerson. Implementer MAY use the additional-requester extension for these additional requester types added in FHIR R6.

When a health or health-related domain is specified as an additional category value, DiagnosticReport.code SHOULD be drawn from the corresponding domain-based value set as discussed on the domains page.

SHALL support searching using the combination of the patient and category search parameters:

SHALL support searching using the combination of the patient and code search parameters:

SHOULD support search by multiple report codes.

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

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

SHOULD support searching using the combination of the patient and code and date search parameters:

SHOULD support search by multiple report codes.

An Observation without a value, SHALL include a reason why the data is absent unless there are component observations. Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason.

When a health or health-related domain is specified as an additional category value, Observation.code SHOULD be drawn from the corresponding domain-based value set as discussed below and on the domains page.

SHALL support searching using the combination of the patient and category search parameters:

SHALL support searching using the combination of the patient and code search parameters:

SHOULD support search by multiple report codes.

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

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

SHOULD support searching using the combination of the patient and code and date search parameters:

SHOULD support search by multiple report codes.

These observations represent a specific question or observation, so the Observation.value element SHOULD be populated and the hasMember list SHALL be empty.

An Observation without a value, SHALL include a reason why the data is absent unless there are component observations. Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason.

When a health or health-related domain is specified as an additional category value, Observation.code SHOULD be drawn from the corresponding domain-based value set as discussed below and on the domains page.

Where a preferred value set contains a code to describe a needed concept, servers SHOULD use that code.

SHALL support searching using the combination of the patient and category search parameters:

SHALL support searching using the combination of the patient and code search parameters:

SHOULD support search by multiple report codes.

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

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

SHOULD support searching using the combination of the patient and code and date search parameters:

SHOULD support search by multiple report codes.

Implementers of this IG SHOULD include at least one category from the Domain Category value set on each observation instance conformant to this guide.

Additionally, the code of the instance SHOULD come from the value set associated with the indicated category or categories.

PAC assessment observations SHOULD be categorized into the ICF domain within the “Activities and Participation” category only when the question focuses on a specific activity.

PAC assessment observations that are part of a specific group of questions (e.g.,PHQ-9 or BIMS) or part of a group of questions listed all under the same header question SHOULD be categorized according to the main focus of the grouping header.

All available assessment item resources, such as the question’s available responses, the question text, and the question short name, SHOULD be considered when making categorization decisions.

SHALL be able to populate all Profile data elements that have a minimum cardinality >= 1 and/or flagged as Must Support as defined by that profile’s StructureDefinition.

SHALL conform to the Personal Functioning and Engagement Capability Statement expectations for that Profile’s type.

Data Sources Systems SHALL be capable of populating all data elements as part of the query results as specified by the Personal Functioning and Engagement Capability Statement.

Data Consumer Systems SHALL be capable of displaying the data elements for human use.

Data Consumer Systems SHOULD be capable of storing the data elements for other uses (such as record keeping of data used for clinical use).

Data Consumer Systems SHALL be capable of processing resource instances containing the data element without generating an error or causing the application to fail.

Data Consumer Systems SHALL interpret missing data elements within resources instances as not being present on the Data Sources system’s or as being withheld for privacy or business reasons.

When one of the below assessments is being recorded as an observation, systems SHOULD use the LOINC to ICF Mapping ConceptMaps to populate the PFEDomain category slice with the appropriate ICF code(s).

If the assessment is not in the list, systems SHOULD implement their own mapping for those assessments.

Systems SHOULD retain the original LOINC-coded observation while using the mapped ICF code(s) for PFEDomain categorization.

All implementers of the Personal Functioning and Engagement IG SHOULD follow the HL7® FHIR® Security guidance, Security and Privacy Module, the FHIR Implementer’s Safety Checklist guidance as defined in the FHIR standard, and US Core security recommendations where applicable and not otherwise superseded by this section of the Personal Functioning and Engagement IG.

In order to protect sensitive patient data while in transit between systems, the exchange of information using the Personal Functioning and Engagement IG SHALL support Transport Layer Security (TLS) Protocol Version 1.2 (RFC5246) or a more recent version of TLS for transport layer security.

Server implementations that expect to support browser-based javascript applications SHOULD enable Cross-Origin Resource Sharing (CORS) for REST operations.

To prevent unauthorized access to sensitive data, implementers SHALL use at least one of the following:

1. The security requirements from theUS Core Implementation Guide,
2. TheSMART on FHIR App Launch Framework,
3. SMART on FHIR Backend Services,
4. Mutually authenticated TLS, or
5. Unified Data Access Profiles (UDAP)recommended by the ONC FHIR At Scale Taskforce (FAST) security tiger team.

The Structured Data Capture FHIR IG provides a methodology for capturing this information within FHIR both in its raw and in its discrete structured form. This page provides guidance on how tools like the SDC Questionnaire and US Core QuestionnaireResponse resources MAY be used with this IG.

When representing formal assessments with complex structures as FHIR Observations, each panel and question SHALL be mapped to an individual Observation instance, with panels represented using the collection profile and questions represented using the single observation profile.

Parent-child links: parent observations SHALL contain references to each child observation instance, including nested panels and specific questions using the hasMember element.

Derivation links: observations derived from other questions, such as summary scores, SHOULD point to the observations that the result is derived from using the derivedFrom element.