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)

This PACIO Re-Assessment Timepoints implementation guide describes a means to break up extended Post-Acute admissions into consumable blocks that can reflect the evolution of care over time of the encounter or episode of care.

Post-Acute Admissions extend over much longer periods of time than the encounters in the Acute and Ambulatory Care Settings, often going for several months or even years. Over the course of these time periods the patient condition and therefore the care being provided is changing - for example in Home Health the goal is rehabilitation so Care Plans, Medications, and Orders are all likely 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 - regulatory and conditions of participation, payer and revenue cycle requirements, and provider specific processes and protocols. In settings like Home Health and SNF, there are defined Medicare assessment instruments that must be completed every X number of days (varies by care setting); the results of said assessment drive the Care Plan for the next X number of days; if a patient has a pain management Care Plan, and their pain scores are down then they may have their Opioid drug dosages reduced or eliminated. If the patient's ambulation is improving, then we may see interventions focused 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 no choice but to sift through months worth of information rather than focusing on a given period or periods most relevant to the need of the application, patient, or other entity.

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.
5. Support the searchParameters on each profile individually and in combination.

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

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: