PACIO Re-Assessment Timepoints Implementation Guide
1.0.0 - STU 1 US

This page is part of the PACIO Re-Assessment Timepoints Implementation Guide (v1.0.0: STU 1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

CapabilityStatement: Re-Assessment Timepoints Capability Statement

Official URL: http://hl7.org/fhir/us/pacio-rt/CapabilityStatement/rt-cs Version: 1.0.0
Active as of 2022-09-06 Computable Name: ReAssessmentTimepointCapabilityStatement

The Re-Assessment Timepoints IG describes a means to break up extended Post-Acute admissions into consumable blocks that can reflect the evolution of care over time for an encounter or episode of care.

On average, Post-Acute Admissions extend over much longer periods of time than encounters in the Acute and Ambulatory Care Settings, often spanning several months or even years. Over the course of these time periods, the patient condition and therefore the care provided is changing constantly. For example, in Home Health the goal is rehabilitation; Care Plans, Medications, and Orders all likely are changing throughout an admission that could last several months. Already in existence within post-acute care settings are periods of time structured by a variety of stakeholders, some more rigid than others, such as regulations and conditions of participation, payer and revenue cycle requirements, and provider specific processes and protocols. In settings like Home Health and Skilled Nursing Facilities (SNF), there are Medicare assessment instruments that providers must complete at specified intervals thatvary by care setting; the results of these assessments drive the Care Plan until a subsequent assessment. If a patient has a pain management Care Plan and their pain levels improve, then they may have their Opioid drug dosages reduced or eliminated. If a patient’s ambulation is improving, then the care team may focus interventions on more complex exercises. These periods of time, defined by many different drivers, have direct impact on how data is made available outside of an EMR. Without a structure in place to hold this information, a connecting application or patient would have to sift through months of information, rather than focusing on a given period or periods most relevant to the needs of the application, patient, or other entity.

Raw OpenAPI-Swagger Definition file | Download

Re-Assessment Timepoints Capability Statement

  • Implementation Guide Version: 0.0.1
  • FHIR Version: 4.0.1
  • Supported formats: xml, json
  • Published: 2021-06-17
  • Published by: HL7 Community Based Care and Privacy Working Group (CBCP WG)

FHIR RESTful Capabilities

The Re-Assessment Timepoints 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 re-assessment timepoints interactions.

The Re-Assessment Timepoints Server SHOULD:

  1. Support xml source formats for all Re-Assessment Timepoints interactions.

Security:

  1. A server SHALL reject any unauthorized requests by returning an 'HTTP 401' unauthorized response code.

RESTful Capabilities by Resource/Profile:

Summary of Search Criteria

Resource TypeSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
EncounterReassessment-Timepoints-Encounter _id, account, appointment, based-on, class, date, diagnosis, episode-of-care, identifier, length, location, location-period, part-of, participant, participant-type, patient, practitioner, reason-code, reason-reference, service-provider, special-arrangement, status, subject, type

Encounter

Conformance Expectation: SHALL

Supported Profiles: Reassessment-Timepoints-Encounter

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a Encounter resource using:
    GET [base]/Encounter/[id]

  • A Server SHOULD be capable of returning a Encounter resource using:
    GET [base]/Encounter/[id]/_history/vid

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL_id token GET [base]/Encounter?_id=[id]
MAYaccount reference GET [base]/Encounter?account=[account]
MAYappointment reference GET [base]/Encounter?appointment=[appointment]
SHOULDbased-on reference GET [base]/Encounter?based-on=[based-on]
MAYclass token GET [base]/Encounter?class=[system]|[code]
SHALLdate date GET [base]/Encounter?date=[date]
SHOULDdiagnosis reference GET [base]/Encounter?diagnosis=[diagnosis]
SHALLepisode-of-care reference GET [base]/Encounter?episode-of-care=[episode-of-care]
MAYidentifier token GET [base]/Encounter?identifier=[system]|[code]
MAYlength quantity GET [base]/Encounter?length=[length]
MAYlocation reference GET [base]/Encounter?location=[location]
MAYlocation-period date GET [base]/Encounter?location-period=[location-period]
SHALLpart-of reference GET [base]/Encounter?part-of=[part-of]
MAYparticipant reference GET [base]/Encounter?participant=[participant]
MAYparticipant-type token GET [base]/Encounter?participant-type=[system]|[code]
SHALLpatient reference GET [base]/Encounter?patient=[patient]
MAYpractitioner reference GET [base]/Encounter?practitioner=[practitioner]
MAYreason-code token GET [base]/Encounter?reason-code=[system]|[code]
SHOULDreason-reference reference GET [base]/Encounter?reason-reference=[reason-reference]
SHOULDservice-provider reference GET [base]/Encounter?service-provider=[service-provider]
MAYspecial-arrangement token GET [base]/Encounter?special-arrangement=[system]|[code]
SHOULDstatus token GET [base]/Encounter?status=[status]
MAYsubject reference GET [base]/Encounter?subject=[subject]
MAYtype token GET [base]/Encounter?type=[system]|[code]

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example
SHALL patient + date reference+date GET [base]/Encounter?patient=[patient]&date=[date]
SHALL part-of + date reference+date GET [base]/Encounter?part-of=[part-of]&date=[date]
In addition, search parameters which are supported individually SHOULD also be supported in combination with any set of other individually supported search parameters.