PACIO Personal Functioning and Engagement Implementation Guide
1.0.0 - STU1 United States of America flag

This page is part of the PACIO Personal Functioning and Engagement Implementation Guide (v1.0.0: STU 1) based on FHIR (HL7® FHIR® Standard) 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: Personal Functioning and Engagement Capability Statement

Official URL: http://hl7.org/fhir/us/pacio-pfe/CapabilityStatement/pacio-pfe-cap Version: 1.0.0
Draft as of 2022-08-12 Computable Name: Personal_Functioning_And_Engagement_CapabilityStatement

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

Raw OpenAPI-Swagger Definition file | Download

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

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
Observation ♦ create ♦ , update ♦ , delete ▿ , read ♦ , vread ⋄ , history-instance ⋄ , history-type ▿ , search-type ♦ , patch ▿ Personal Functioning and Engagement Clinical Test Observation, Personal Functioning and Engagement Collection, Personal Functioning and Engagement Single Observation date ▿ , combo-data-absent-reason ▿ , code ▿ , combo-code-value-quantity ▿ , subject ▿ , component-data-absent-reason ▿ , value-concept ▿ , value-date ▿ , code-value-string ▿ , component-code-value-quantity ▿ , based-on ▿ , code-value-date ▿ , patient ▿ , specimen ▿ , component-code ▿ , code-value-quantity ▿ , combo-code-value-concept ▿ , value-string ▿ , identifier ▿ , performer ▿ , combo-code ▿ , method ▿ , value-quantity ▿ , component-value-quantity ▿ , data-absent-reason ▿ , combo-value-quantity ▿ , encounter ▿ , code-value-concept ▿ , component-code-value-concept ▿ , component-value-concept ▿ , category ▿ , device ▿ , combo-value-concept ▿ , status ▿ Observation.subject ▿ , Observation.based-on ▿ , Observation.patient ▿ , Observation.specimen ▿ , Observation.context ▿ , Observation.performer ▿ , Observation.encounter ▿ , Observation.device ▿ ChargeItem.service ▿ , ClinicalImpression.finding-ref ▿ , ClinicalImpression.investigation ▿ , DiagnosticReport.result ▿ , Immunization.reaction ▿ , ImmunizationRecommendation.information ▿ , MedicationStatement.part-of ▿ , Procedure.part-of ▿ , QuestionnaireResponse.parent ▿
DiagnosticReport ▿ create ♦ , update ♦ , delete ▿ , read ♦ , vread ⋄ , history-instance ⋄ , history-type ▿ , search-type ♦ , patch ▿ Personal Functioning and Engagement Narrative History of Status date ▿ , code ▿ , patient ♦ , identifier ▿ , encounter ▿ DiagnosticReport.based-on ▿ , DiagnosticReport.subject ▿ , DiagnosticReport.patient ▿ , DiagnosticReport.encounter ▿ , DiagnosticReport.media ▿ , DiagnosticReport.performer ▿ , DiagnosticReport.result ▿ , DiagnosticReport.results-interpreter ▿ , DiagnosticReport.specimen ▿
DeviceUseStatement ⋄ create ⋄ , update ⋄ , delete ⋄ , read ⋄ , vread ▿ , history-instance ▿ , history-type ▿ , search-type ▿ , patch ▿ Personal Functioning and Engagement Use of Device identifier ▿ , subject ▿ , patient ▿ , device ▿ DeviceUseStatement.subject ▿ , DeviceUseStatement.patient ▿ , DeviceUseStatement.device ▿

Observation

Conformance Expectation:SHALL

Supported Profiles:

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

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

  • date (date):

    Obtained date/time. If the obtained element is a period, a date that falls in the period

  • combo-data-absent-reason (token):

    The reason why the expected value in the element Observation.value[x] or Observation.component.value[x] is missing.

  • code (token):

    The code of the observation type

  • combo-code-value-quantity (composite):

    Code and quantity value parameter pair, including in components

  • subject (reference):

    The subject that the observation is about

  • component-data-absent-reason (token):

    The reason why the expected value in the element Observation.component.value[x] is missing.

  • value-concept (token):

    The value of the observation, if the value is a CodeableConcept

  • value-date (date):

    The value of the observation, if the value is a date or period of time

  • code-value-string (composite):

    Code and string value parameter pair

  • component-code-value-quantity (composite):

    Component code and component quantity value parameter pair

  • based-on (reference):

    Reference to the test or procedure request.

  • code-value-date (composite):

    Code and date/time value parameter pair

  • patient (reference):

    The subject that the observation is about (if patient)

  • specimen (reference):

    Specimen used for this observation

  • component-code (token):

    The component code of the observation type

  • code-value-quantity (composite):

    Code and quantity value parameter pair

  • combo-code-value-concept (composite):

    Code and coded value parameter pair, including in components

  • value-string (string):

    The value of the observation, if the value is a string, and also searches in CodeableConcept.text

  • identifier (token):

    The unique id for a particular observation

  • performer (reference):

    Who performed the observation

  • combo-code (token):

    The code of the observation type or component type

  • method (token):

    The method used for the observation

  • value-quantity (quantity):

    The value of the observation, if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)

  • component-value-quantity (quantity):

    The value of the component observation, if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)

  • data-absent-reason (token):

    The reason why the expected value in the element Observation.value[x] is missing.

  • combo-value-quantity (quantity):

    The value or component value of the observation, if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)

  • encounter (reference):

    Encounter related to the observation

  • code-value-concept (composite):

    Code and coded value parameter pair

  • component-code-value-concept (composite):

    Component code and component coded value parameter pair

  • component-value-concept (token):

    The value of the component observation, if the value is a CodeableConcept

  • category (token):

    The classification of the type of observation

  • device (reference):

    The Device that generated the observation data.

  • combo-value-concept (token):

    The value or component value of the observation, if the value is a CodeableConcept

  • status (token):

    The status of the observation

DiagnosticReport

Conformance Expectation:MAY

Supported Profiles:

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:

Conformance Parameter Type Example
SHALL patient reference GET [base]/DiagnosticReport?patient=[type]/[id]

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

  • date (date):

    Obtained date/time. If the obtained element is a period, a date that falls in the period

  • code (token):

    The code of the report type

  • patient (reference):

    The subject that the report is about (if patient)

  • identifier (token):

    The unique id for a particular report

  • encounter (reference):

    Encounter related to the report

DeviceUseStatement

Conformance Expectation:SHOULD

Supported Profiles:

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

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

  • identifier (token):

    Search by identifier

  • subject (reference):

    Search by subject

  • patient (reference):

    Search by subject - a patient

  • device (reference):

    Search by device