Personal Functioning and Engagement Capability Statement

• Official URL:http://hl7.org/fhir/us/pacio-pfe/CapabilityStatement/pacio-pfe-cap
• Implementation Guide Version: 1.0.0-ballot
• FHIR Version: 4.0.1
• Intended Use: Requirements
• Supported Formats: XML, JSON
• Published: 2022-08-12 00:00:00+00:00
• Published by: HL7 International - Patient Care
• Status: Draft

This Capability Statement defines the expected capabilities of a Personal Functioning and Engagement FHIR server conforming to the Personal Functioning and Engagement Implementation Guide.

FHIR Server RESTful Capabilities

The PFE Server SHALL:

1. Support all profiles defined in this Implementation Guide.
2. Implement the RESTful behavior according to the FHIR specification.
3. Return the following response classes:
   • (Status 400): invalid parameter
   • (Status 401/4xx): unauthorized request
   • (Status 403): insufficient scope
   • (Status 404): unknown resource
   • (Status 410): deleted resource.
4. Support json source formats for all PFE interactions.
5. Support the searchParameters on each profile individually and in combination.

The PFE Server SHOULD:

1. Support xml source formats for all PFE interactions.

Security:

1. See the Guidance section for requirements and recommendations.
2. A server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found" response code.

Summary of Server Wide Interactions

• MAY support the batch interaction.
• MAY support the search-system interaction.

Summary of Server Wide Search Parameters

• MAY support the _content search parameter.
• SHALL support the _id search parameter.
• SHALL support the _lastUpdated search parameter.
• MAY support the _security search parameter.
• MAY support the _text search parameter.
• MAY support the _query search parameter.

RESTful Capabilities by Resource/Profile:

Summary

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

Observation

Conformance Expectation:SHALL

Supported Profiles:

• Personal Functioning and Engagement Clinical Test Observation,
• Personal Functioning and Engagement Collection,
• Personal Functioning and Engagement Single Observation

Reference Policy: literal, logical

Profile Interaction Summary:

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

Modify Criteria:

• A Server SHALL be capable of creating an Observation resource using:POST [base]/Observation/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional create of an Observation resource using header:If-None-Exist: [search parameters]
• A Server SHALL be capable of updating an existing Observation resource using:PUT [base]/Observation/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional update of an Observation resource using:PUT [base]/[Observation]?[search parameters]
• A Server MAY be capable of deleting an Observation resource using:DELETE [base]/Observation/[id]
  • A Server MAY support multiple conditional delete of Observation resources using:DELETE [base]/[Observation]/?[search parameters]
• A Server MAY be capable of patching an existing Observation resource using:PATCH [base]/Observation/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

• A Server SHALL be capable of returning an Observation resource using:GET [base]/Observation/[id]
• A Server SHOULD be capable of returning an Observation resource using:GET [base]/Observation/[id]/_history/vid
• A Server SHALL be capable of returning resources matching a search query using:GET [base]/Observation/[id]{?[parameters]{&_format=[mime-type]}}
• A Server SHOULD be capable of returning a history of a Observation using:GET [base]/Observation/[id]/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of returning the history of Observation resources using:GET [base]/Observation/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of supporting the following _includes:
  • Observation.subject - GET [base]/Observation?[parameter=value]&_include=Observation.subject
  • Observation.based-on - GET [base]/Observation?[parameter=value]&_include=Observation.based-on
  • Observation.patient - GET [base]/Observation?[parameter=value]&_include=Observation.patient
  • Observation.specimen - GET [base]/Observation?[parameter=value]&_include=Observation.specimen
  • Observation.context - GET [base]/Observation?[parameter=value]&_include=Observation.context
  • Observation.performer - GET [base]/Observation?[parameter=value]&_include=Observation.performer
  • Observation.encounter - GET [base]/Observation?[parameter=value]&_include=Observation.encounter
  • Observation.device - GET [base]/Observation?[parameter=value]&_include=Observation.device
• A Server MAY be capable of supporting the following _revincludes:
  • ChargeItem.service - GET [base]/Observation?[parameter=value]&_revinclude=ChargeItem.service
  • ClinicalImpression.finding-ref - GET [base]/Observation?[parameter=value]&_revinclude=ClinicalImpression.finding-ref
  • ClinicalImpression.investigation - GET [base]/Observation?[parameter=value]&_revinclude=ClinicalImpression.investigation
  • DiagnosticReport.result - GET [base]/Observation?[parameter=value]&_revinclude=DiagnosticReport.result
  • Immunization.reaction - GET [base]/Observation?[parameter=value]&_revinclude=Immunization.reaction
  • ImmunizationRecommendation.information - GET [base]/Observation?[parameter=value]&_revinclude=ImmunizationRecommendation.information
  • MedicationStatement.part-of - GET [base]/Observation?[parameter=value]&_revinclude=MedicationStatement.part-of
  • Procedure.part-of - GET [base]/Observation?[parameter=value]&_revinclude=Procedure.part-of
  • QuestionnaireResponse.parent - GET [base]/Observation?[parameter=value]&_revinclude=QuestionnaireResponse.parent

DiagnosticReport

Conformance Expectation:MAY

Supported Profiles:

• Personal Functioning and Engagement Narrative History of Status,
• Personal Functioning and Engagement Diagnostic Report Note Exchange Profile

Reference Policy: literal, logical

Profile Interaction Summary:

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

Modify Criteria:

• A Server SHALL be capable of creating a DiagnosticReport resource using:POST [base]/DiagnosticReport/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional create of a DiagnosticReport resource using header:If-None-Exist: [search parameters]
• A Server SHALL be capable of updating an existing DiagnosticReport resource using:PUT [base]/DiagnosticReport/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional update of a DiagnosticReport resource using:PUT [base]/[DiagnosticReport]?[search parameters]
• A Server MAY be capable of deleting a DiagnosticReport resource using:DELETE [base]/DiagnosticReport/[id]
  • A Server MAY support multiple conditional delete of DiagnosticReport resources using:DELETE [base]/[DiagnosticReport]/?[search parameters]
• A Server MAY be capable of patching an existing DiagnosticReport resource using:PATCH [base]/DiagnosticReport/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

• A Server SHALL be capable of returning a DiagnosticReport resource using:GET [base]/DiagnosticReport/[id]
• A Server SHOULD be capable of returning a DiagnosticReport resource using:GET [base]/DiagnosticReport/[id]/_history/vid
• A Server SHALL be capable of returning resources matching a search query using:GET [base]/DiagnosticReport/[id]{?[parameters]{&_format=[mime-type]}}
• A Server SHOULD be capable of returning a history of a DiagnosticReport using:GET [base]/DiagnosticReport/[id]/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of returning the history of DiagnosticReport resources using:GET [base]/DiagnosticReport/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of supporting the following _includes:
  • DiagnosticReport.based-on - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.based-on
  • DiagnosticReport.subject - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.subject
  • DiagnosticReport.patient - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.patient
  • DiagnosticReport.encounter - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.encounter
  • DiagnosticReport.media - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.media
  • DiagnosticReport.performer - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.performer
  • DiagnosticReport.result - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.result
  • DiagnosticReport.results-interpreter - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.results-interpreter
  • DiagnosticReport.specimen - GET [base]/DiagnosticReport?[parameter=value]&_include=DiagnosticReport.specimen

Search Parameter Summary:

DeviceUseStatement

Conformance Expectation:SHOULD

Supported Profiles:

• Personal Functioning and Engagement Use of Device

Reference Policy: literal, logical

Profile Interaction Summary:

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

Modify Criteria:

• A Server SHOULD be capable of creating a DeviceUseStatement resource using:POST [base]/DeviceUseStatement/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional create of a DeviceUseStatement resource using header:If-None-Exist: [search parameters]
• A Server SHOULD be capable of updating an existing DeviceUseStatement resource using:PUT [base]/DeviceUseStatement/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional update of a DeviceUseStatement resource using:PUT [base]/[DeviceUseStatement]?[search parameters]
• A Server SHOULD be capable of deleting a DeviceUseStatement resource using:DELETE [base]/DeviceUseStatement/[id]
  • A Server MAY support multiple conditional delete of DeviceUseStatement resources using:DELETE [base]/[DeviceUseStatement]/?[search parameters]
• A Server MAY be capable of patching an existing DeviceUseStatement resource using:PATCH [base]/DeviceUseStatement/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a DeviceUseStatement resource using:GET [base]/DeviceUseStatement/[id]
• A Server MAY be capable of returning a DeviceUseStatement resource using:GET [base]/DeviceUseStatement/[id]/_history/vid
• A Server MAY be capable of returning resources matching a search query using:GET [base]/DeviceUseStatement/[id]{?[parameters]{&_format=[mime-type]}}
• A Server MAY be capable of returning a history of a DeviceUseStatement using:GET [base]/DeviceUseStatement/[id]/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of returning the history of DeviceUseStatement resources using:GET [base]/DeviceUseStatement/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of supporting the following _includes:
  • DeviceUseStatement.subject - GET [base]/DeviceUseStatement?[parameter=value]&_include=DeviceUseStatement.subject
  • DeviceUseStatement.patient - GET [base]/DeviceUseStatement?[parameter=value]&_include=DeviceUseStatement.patient
  • DeviceUseStatement.device - GET [base]/DeviceUseStatement?[parameter=value]&_include=DeviceUseStatement.device

Condition

Conformance Expectation:SHOULD

Supported Profiles:

• Personal Functioning and Engagement Condition Encounter Diagnosis Profile,
• Personal Functioning and Engagement Condition Problems and Health Concerns Profile

Reference Policy: literal, logical

Profile Interaction Summary:

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

Modify Criteria:

• A Server SHOULD be capable of creating a Condition resource using:POST [base]/Condition/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional create of a Condition resource using header:If-None-Exist: [search parameters]
• A Server SHOULD be capable of updating an existing Condition resource using:PUT [base]/Condition/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional update of a Condition resource using:PUT [base]/[Condition]?[search parameters]
• A Server SHOULD be capable of deleting a Condition resource using:DELETE [base]/Condition/[id]
  • A Server MAY support multiple conditional delete of Condition resources using:DELETE [base]/[Condition]/?[search parameters]
• A Server MAY be capable of patching an existing Condition resource using:PATCH [base]/Condition/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a Condition resource using:GET [base]/Condition/[id]
• A Server MAY be capable of returning a Condition resource using:GET [base]/Condition/[id]/_history/vid
• A Server MAY be capable of returning resources matching a search query using:GET [base]/Condition/[id]{?[parameters]{&_format=[mime-type]}}
• A Server MAY be capable of returning a history of a Condition using:GET [base]/Condition/[id]/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of returning the history of Condition resources using:GET [base]/Condition/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of supporting the following _includes:
  • Condition.identifier - GET [base]/Condition?[parameter=value]&_include=Condition.identifier
  • Condition.subject - GET [base]/Condition?[parameter=value]&_include=Condition.subject
  • Condition.bodySite - GET [base]/Condition?[parameter=value]&_include=Condition.bodySite
  • Condition.asserter - GET [base]/Condition?[parameter=value]&_include=Condition.asserter
  • recordedDate - GET [base]/Condition?[parameter=value]&_include=recordedDate
  • code - GET [base]/Condition?[parameter=value]&_include=code
  • encounter - GET [base]/Condition?[parameter=value]&_include=encounter

Goal

Conformance Expectation:SHOULD

Supported Profiles:

• Personal Functioning and Engagement Goal Profile

Reference Policy: literal, logical

Profile Interaction Summary:

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

Modify Criteria:

• A Server SHOULD be capable of creating a Goal resource using:POST [base]/Goal/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional create of a Goal resource using header:If-None-Exist: [search parameters]
• A Server SHOULD be capable of updating an existing Goal resource using:PUT [base]/Goal/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional update of a Goal resource using:PUT [base]/[Goal]?[search parameters]
• A Server SHOULD be capable of deleting a Goal resource using:DELETE [base]/Goal/[id]
  • A Server MAY support multiple conditional delete of Goal resources using:DELETE [base]/[Goal]/?[search parameters]
• A Server MAY be capable of patching an existing Goal resource using:PATCH [base]/Goal/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a Goal resource using:GET [base]/Goal/[id]
• A Server MAY be capable of returning a Goal resource using:GET [base]/Goal/[id]/_history/vid
• A Server MAY be capable of returning resources matching a search query using:GET [base]/Goal/[id]{?[parameters]{&_format=[mime-type]}}
• A Server MAY be capable of returning a history of a Goal using:GET [base]/Goal/[id]/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of returning the history of Goal resources using:GET [base]/Goal/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of supporting the following _includes:
  • Goal.identifier - GET [base]/Goal?[parameter=value]&_include=Goal.identifier
  • Goal.subject - GET [base]/Goal?[parameter=value]&_include=Goal.subject
  • Goal.patient - GET [base]/Goal?[parameter=value]&_include=Goal.patient
  • Goal.achievementStatus - GET [base]/Goal?[parameter=value]&_include=Goal.achievementStatus
  • Goal.addresses - GET [base]/Goal?[parameter=value]&_include=Goal.addresses

NutritionOrder

Conformance Expectation:SHOULD

Supported Profiles:

• Personal Functioning and Engagement Nutrition Order Profile

Reference Policy: literal, logical

Profile Interaction Summary:

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

Modify Criteria:

• A Server SHOULD be capable of creating a NutritionOrder resource using:POST [base]/NutritionOrder/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional create of a NutritionOrder resource using header:If-None-Exist: [search parameters]
• A Server SHOULD be capable of updating an existing NutritionOrder resource using:PUT [base]/NutritionOrder/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional update of a NutritionOrder resource using:PUT [base]/[NutritionOrder]?[search parameters]
• A Server SHOULD be capable of deleting a NutritionOrder resource using:DELETE [base]/NutritionOrder/[id]
  • A Server MAY support multiple conditional delete of NutritionOrder resources using:DELETE [base]/[NutritionOrder]/?[search parameters]
• A Server MAY be capable of patching an existing NutritionOrder resource using:PATCH [base]/NutritionOrder/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a NutritionOrder resource using:GET [base]/NutritionOrder/[id]
• A Server MAY be capable of returning a NutritionOrder resource using:GET [base]/NutritionOrder/[id]/_history/vid
• A Server MAY be capable of returning resources matching a search query using:GET [base]/NutritionOrder/[id]{?[parameters]{&_format=[mime-type]}}
• A Server MAY be capable of returning a history of a NutritionOrder using:GET [base]/NutritionOrder/[id]/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of returning the history of NutritionOrder resources using:GET [base]/NutritionOrder/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of supporting the following _includes:
  • NutritionOrder.identifier - GET [base]/NutritionOrder?[parameter=value]&_include=NutritionOrder.identifier
  • NutritionOrder.subject - GET [base]/NutritionOrder?[parameter=value]&_include=NutritionOrder.subject
  • NutritionOrder.patient - GET [base]/NutritionOrder?[parameter=value]&_include=NutritionOrder.patient
  • NutritionOrder.encounter - GET [base]/NutritionOrder?[parameter=value]&_include=NutritionOrder.encounter
  • NutritionOrder.orderer - GET [base]/NutritionOrder?[parameter=value]&_include=NutritionOrder.orderer
  • NutritionOrder.status - GET [base]/NutritionOrder?[parameter=value]&_include=NutritionOrder.status

ServiceRequest

Conformance Expectation:SHOULD

Supported Profiles:

• Personal Functioning and Engagement Service Request Profile

Reference Policy: literal, logical

Profile Interaction Summary:

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

Modify Criteria:

• A Server SHOULD be capable of creating a ServiceRequest resource using:POST [base]/ServiceRequest/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional create of a ServiceRequest resource using header:If-None-Exist: [search parameters]
• A Server SHOULD be capable of updating an existing ServiceRequest resource using:PUT [base]/ServiceRequest/[id]{?_format=[mime-type]}
  • A Server MAY be capable of the conditional update of a ServiceRequest resource using:PUT [base]/[ServiceRequest]?[search parameters]
• A Server SHOULD be capable of deleting a ServiceRequest resource using:DELETE [base]/ServiceRequest/[id]
  • A Server MAY support multiple conditional delete of ServiceRequest resources using:DELETE [base]/[ServiceRequest]/?[search parameters]
• A Server MAY be capable of patching an existing ServiceRequest resource using:PATCH [base]/ServiceRequest/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a ServiceRequest resource using:GET [base]/ServiceRequest/[id]
• A Server MAY be capable of returning a ServiceRequest resource using:GET [base]/ServiceRequest/[id]/_history/vid
• A Server MAY be capable of returning resources matching a search query using:GET [base]/ServiceRequest/[id]{?[parameters]{&_format=[mime-type]}}
• A Server MAY be capable of returning a history of a ServiceRequest using:GET [base]/ServiceRequest/[id]/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of returning the history of ServiceRequest resources using:GET [base]/ServiceRequest/_history{?[parameters]&_format=[mime-type]}
• A Server MAY be capable of supporting the following _includes:
  • ServiceRequest.identifier - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest.identifier
  • ServiceRequest.subject - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest.subject
  • ServiceRequest.patient - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest.patient
  • ServiceRequest.status - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest.status
  • ServiceRequest.code - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest.code
  • ServiceRequest.requester - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest.requester
  • ServiceRequest.performer - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest.performer
  • ServiceRequest.reasonReference - GET [base]/ServiceRequest?[parameter=value]&_include=ServiceRequest.reasonReference