PACIO Personal Functioning and Engagement Implementation Guide
3.0.0-ballot - STU 3 Ballot United States of America flag

PACIO Personal Functioning and Engagement Implementation Guide, published by HL7 International / Patient Care. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-pacio-pfe/ and changes regularly. See the Directory of published versions

Formal Specification

Page standards status: Trial-use

This section defines additional requirements and guidance relevant to this IG as a whole. The FHIR Conformance Rules define the conformance verbs — SHALL, SHOULD, and MAY — used in this IG.

Claiming Conformance to a Personal Functioning and Engagement Profile

To claim conformance to a Profile in this IG, servers:

Must Support

The following rules apply to all Personal Functioning and Engagement Profile elements marked as Must Support. Must Support on any profile data element is interpreted as follows:

Data Source System Requirements

Data Consumer System Requirements

  • Data Consumer Systems SHALL be capable of displaying the data elements for human use.§CONF-50
  • Data Consumer Systems SHOULD be capable of storing the data elements for other uses (such as record keeping of data used for clinical use).§CONF-51
  • Data Consumer Systems SHALL be capable of processing resource instances containing the data element without generating an error or causing the application to fail.§CONF-52
  • 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.§CONF-53

Profiles used by this IG, but defined in other IGs, inherit the definition of Must Support from their respective guides.

Dependencies

This Implementation Guide depends on US Core v9.0.0 (USCDI 6) as its primary base. Wherever possible, PFE profiles strive to comply with US Core v6.1.0 (USCDI 3), v7.0.0 (USCDI 4), and v8.0.1 (USCDI 5), simplifying implementation for those who need to support varying regulatory expectations over time. Implementers can use any of these US Core versions when implementing this IG, so long as the profile requirements defined in this guide are satisfied.

Use of ConceptMap for ICF Domain Categorization

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).§CONF-54

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

This applies to the following profiles:

ICF concepts used for domain categorization are generally broader than the source LOINC observation concepts. As a result, mapping a LOINC code to an ICF code may reduce specificity and can involve loss of information. Systems SHOULD retain the original LOINC-coded observation while using the mapped ICF code(s) for PFEDomain categorization.§CONF-56

  • LOINC was selected for this mapping as it includes codes for the measure items and response options included in the mapping.
  • The ICF was specifically chosen through a consensus process with the PFE community after reviewing several code systems and identifying that ICF was the most applicable to capturing PAC data. The purpose of integrating the ICF into the PFE IG and this mapping is to support healthcare system- and population-level sharing and use of data regarding functioning and disability that complements clinical data.

Contact the PACIO project at info@pacioproject.org for detailed information about the rationale for choosing LOINC and ICF, and for specific methods used to develop and validate the mappings.

Conformance Statement Summary

The following table lists the free-text conformance statements in this IG. It is a summary only; implementers should use each linked statement in its original context and also consider computable requirements in profiles, capability statements, and value sets.

IdExpectationConditional?Rule
 SHALL
 SHOULD
 MAY		 Yes
 No
 Any
§CONF-1SHALL PACIO Personal Functioning and Engagement Servers SHALL support the capabilities described in the US Core Server CapabilityStatement.
§CONF-2SHALL 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.
§CONF-3SHALL The Observation.value and Observation.component elements SHALL be empty.
§CONF-4SHOULDXWhen 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.
§CONF-5SHALL SHALL support searching using the combination of the patient and category search parameters:
§CONF-6SHALL SHALL support searching using the combination of the patient and code search parameters:
§CONF-7SHOULD SHOULD support search by multiple report codes.
§CONF-8SHALL SHALL support searching using the combination of the patient and category and date search parameters:
§CONF-9SHOULD SHOULD support searching using the combination of the patient and category and status search parameters:
§CONF-10SHOULD SHOULD support searching using the combination of the patient and code and date search parameters:
§CONF-11SHOULD SHOULD support search by multiple report codes.
§CONF-12SHALL Implementations SHALL follow the US Core Device Profile UDI Specific Implementation Guidance when exchanging Unique Device Identifier (UDI) information.
§CONF-13MAY 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.
§CONF-14SHOULDXWhen 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.
§CONF-15SHALL SHALL support searching using the combination of the patient and category search parameters:
§CONF-16SHALL SHALL support searching using the combination of the patient and code search parameters:
§CONF-17SHOULD SHOULD support search by multiple report codes.
§CONF-18SHALL SHALL support searching using the combination of the patient and category and date search parameters:
§CONF-19SHOULD SHOULD support searching using the combination of the patient and category and status search parameters:
§CONF-20SHOULD SHOULD support searching using the combination of the patient and code and date search parameters:
§CONF-21SHOULD SHOULD support search by multiple report codes.
§CONF-22SHALL 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.
§CONF-23SHOULDXWhen 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.
§CONF-24SHALL SHALL support searching using the combination of the patient and category search parameters:
§CONF-25SHALL SHALL support searching using the combination of the patient and code search parameters:
§CONF-26SHOULD SHOULD support search by multiple report codes.
§CONF-27SHALL SHALL support searching using the combination of the patient and category and date search parameters:
§CONF-28SHOULD SHOULD support searching using the combination of the patient and category and status search parameters:
§CONF-29SHOULD SHOULD support searching using the combination of the patient and code and date search parameters:
§CONF-30SHOULD SHOULD support search by multiple report codes.
§CONF-31SHALL
SHOULD		 These observations represent a specific question or observation, so the Observation.value element SHOULD be populated and the hasMember list SHALL be empty.
§CONF-32SHALL 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.
§CONF-33SHOULDXWhen 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.
§CONF-34SHOULD Where a preferred value set contains a code to describe a needed concept, servers SHOULD use that code.
§CONF-35SHALL SHALL support searching using the combination of the patient and category search parameters:
§CONF-36SHALL SHALL support searching using the combination of the patient and code search parameters:
§CONF-37SHOULD SHOULD support search by multiple report codes.
§CONF-38SHALL SHALL support searching using the combination of the patient and category and date search parameters:
§CONF-39SHOULD SHOULD support searching using the combination of the patient and category and status search parameters:
§CONF-40SHOULD SHOULD support searching using the combination of the patient and code and date search parameters:
§CONF-41SHOULD SHOULD support search by multiple report codes.
§CONF-42SHOULD Implementers of this IG SHOULD include at least one category from the Domain Category value set on each observation instance conformant to this guide.
§CONF-43SHOULD Additionally, the code of the instance SHOULD come from the value set associated with the indicated category or categories.
§CONF-44SHOULDXPAC assessment observations SHOULD be categorized into the ICF domain within the “Activities and Participation” category only when the question focuses on a specific activity.
§CONF-45SHOULDXPAC 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.
§CONF-46SHOULD 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.
§CONF-47SHALL 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.
§CONF-48SHALL SHALL conform to the Personal Functioning and Engagement Capability Statement expectations for that Profile’s type.
§CONF-49SHALL 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.
§CONF-50SHALL Data Consumer Systems SHALL be capable of displaying the data elements for human use.
§CONF-51SHOULD Data Consumer Systems SHOULD be capable of storing the data elements for other uses (such as record keeping of data used for clinical use).
§CONF-52SHALL Data Consumer Systems SHALL be capable of processing resource instances containing the data element without generating an error or causing the application to fail.
§CONF-53SHALL 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.
§CONF-54SHOULDXWhen 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).
§CONF-55SHOULDXIf the assessment is not in the list, systems SHOULD implement their own mapping for those assessments.
§CONF-56SHOULD Systems SHOULD retain the original LOINC-coded observation while using the mapped ICF code(s) for PFEDomain categorization.
§CONF-57SHOULD 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.
§CONF-58SHALL 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.
§CONF-59SHOULD Server implementations that expect to support browser-based javascript applications SHOULD enable Cross-Origin Resource Sharing (CORS) for REST operations.
§CONF-60SHALL

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

§CONF-61MAY 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.
§CONF-62SHALLXWhen 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.
§CONF-63SHALL Parent-child links: parent observations SHALL contain references to each child observation instance, including nested panels and specific questions using the hasMember element.
§CONF-64SHOULD 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.