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
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
The Re-Assessment Timepoints Server SHALL:
The Re-Assessment Timepoints Server SHOULD:
Security:
Summary of Search Criteria
Resource Type | Supported Profiles | Supported Searches | Supported _includes | Supported _revincludes | Supported Operations |
---|---|---|---|---|---|
Encounter | Reassessment-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 |
Conformance Expectation: SHALL
Supported Profiles: Reassessment-Timepoints-Encounter
Reference Policy: resolves
Profile Interaction Summary:
create
,
search-type
,
read
,
update
.vread
,
history-instance
.Fetch and Search Criteria:
GET [base]/Encounter/[id]
GET [base]/Encounter/[id]/_history/vid
Search Parameter Summary:
Conformance | Parameter | Type | Example |
---|---|---|---|
SHALL | _id | token | GET [base]/Encounter?_id=[id] |
MAY | account | reference | GET [base]/Encounter?account=[account] |
MAY | appointment | reference | GET [base]/Encounter?appointment=[appointment] |
SHOULD | based-on | reference | GET [base]/Encounter?based-on=[based-on] |
MAY | class | token | GET [base]/Encounter?class=[system]|[code] |
SHALL | date | date | GET [base]/Encounter?date=[date] |
SHOULD | diagnosis | reference | GET [base]/Encounter?diagnosis=[diagnosis] |
SHALL | episode-of-care | reference | GET [base]/Encounter?episode-of-care=[episode-of-care] |
MAY | identifier | token | GET [base]/Encounter?identifier=[system]|[code] |
MAY | length | quantity | GET [base]/Encounter?length=[length] |
MAY | location | reference | GET [base]/Encounter?location=[location] |
MAY | location-period | date | GET [base]/Encounter?location-period=[location-period] |
SHALL | part-of | reference | GET [base]/Encounter?part-of=[part-of] |
MAY | participant | reference | GET [base]/Encounter?participant=[participant] |
MAY | participant-type | token | GET [base]/Encounter?participant-type=[system]|[code] |
SHALL | patient | reference | GET [base]/Encounter?patient=[patient] |
MAY | practitioner | reference | GET [base]/Encounter?practitioner=[practitioner] |
MAY | reason-code | token | GET [base]/Encounter?reason-code=[system]|[code] |
SHOULD | reason-reference | reference | GET [base]/Encounter?reason-reference=[reason-reference] |
SHOULD | service-provider | reference | GET [base]/Encounter?service-provider=[service-provider] |
MAY | special-arrangement | token | GET [base]/Encounter?special-arrangement=[system]|[code] |
SHOULD | status | token | GET [base]/Encounter?status=[status] |
MAY | subject | reference | GET [base]/Encounter?subject=[subject] |
MAY | type | 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] |