S02 - PWS - ATCH - V to Z - Remote Patient Monitoring Home Telehealth FY 22 09082021.pdf

Version 4.0 Page 1 of 21 September 8, 2021

Attachment V

Remote Patient Monitoring - Home Telehealth

Census Requirements

Patient Census Reporting

Author: George C. Blankenship, Jr.

Creation Date: June 27, 2005

Version Date: September 8, 2021

Version: 4.0

Version 4.0 Page 2 of 21 September 8, 2021

Version History

Date Author Version Change Reference

06/27/2005 Dan Maloney 1.0 Initial Version

07/21/2005 Dan Maloney 1.1 Included home device information and minor clarifications

09/06/2005 Dan Maloney 1.2 Added submission alternatives for vendors who could not meet the HL7 requirement, lowercase names for all XSD element names, addition of non-mandatory home device identifiers, a version number for the XML format and wording changes for clarifications

08/01/2006 Dan Maloney 1.3 Added Level of Care indicator, updated the format of the document, modality name is now mandatory, new file format required by September 1, 2006, HL7 submission required by Oct 1, 2006, other minor updates

02/07/2007 Dan Maloney 1.4 Updated names and descriptions of Levels of Care in Table 2

09/26/2008 Dan Maloney 1.5 Home appliance model and serial made mandatory

02/14/2009 Dan Maloney 1.6 Content updated, standard DMP titles listed, “No DMP Reported” added, Video

Modality added

03/02/2009 Dan Maloney 1.72 Reorganized DMP title table, added co-morbid title guidance, no default for level of care

06/16/2009 Dan Maloney 1.8 Added data age, compliance responses, compliance expected, care coordinator id, clarifications, file rejection error codes

07/24/2009 Linda Foster, Dan Maloney

1.9 Edits per emails and conversations, response rate data field and IVR and Browser entry devices

11/30/09 Linda Foster 2.0 Updated list of standard DMP titles

12/18/2009 Dan Maloney 2.0 Compliance format includes 100.0%, Image modalities, smart phone device

6/21/2010 Linda Foster 2.1 Updated list of standard DMP titles, category of care definitions and response rate metric

7/21/2010 George

Blankenship

2.1 Change tracking based upon version 1.9 and formatting of tables

10/27/2010 Mike Boone 2.1 Change to require ‘NA’ for certain mandatory elements

10/28/2010 Ellen Edmonson 2.1 Clarification points added for data elements for compliance, rr-res and rr-exp.

12/10/2010 Mike Boone 2.2 Edits based on review at weekly Home Telehealth call

Versioning of VHA DMPs to be determined

2/17/2010 Mike Boone 2.2 Clarification of DMP versioning

Version 4.0 Page 3 of 21 September 8, 2021

11/14/2011 George

Blankenship

2.2a Split Census data item out from XML and HL7 syntax.

11/14/2011 George

Blankenship

2.2a Clean up of formatting

11/14/2011 George

Blankenship

2.3a Change author (temporally until new author is selected)

9/5/2013 George

Blankenship

2.3b Finalized document

10/20/2014 George

Blankenship

2.3c Correct version number in document metadata

10/20/2014 George

Blankenship

2.3c Correct COTR

10/20/2014 George

Blankenship

2.3c Correct OTS owner of the data item requirements

10/20/2014 George

Blankenship

2.3c Correct formatting and add references to table where appropriate

10/20/2014 George

Blankenship

2.3c Correct Table 1 Mandatory column to identify those data values that must be present with a defined value, must be present with no defined value, or are optional.

10/20/2014

10/30/2014

11/13/201

5/1/2015

5/11/2015

George

Blankenship

Cathy Buck

2.3c

3.0

3.0

Remove DMP version since the version number is imbedded in the DMP title.

Correct OTS to Telehealth Services

Change Reviewers from Linda Foster to Cathy Buck

Section 3: VistA Inactivation now equals disenrollment (see footnote #2)

Section 5: Response Rate Data Element changed to Response Count Data

Element, information related to response rate calculation removed (done by

VA), all patients are to be included in response count data

Section 6: Mandatory (M) and Mandatory and Verified (MV) indications

Table 1: Patient’s Data Age Element has new entry for never responded (-1). NA options removed. Element for Care Program name removed. Several of the data element examples are now placed in separate tables.

Table 1b: Low Intensity / Low Acuity (L2) Category of Care added

Table 1c2_ Measurements element – no longer includes self-reported

Section 3: Enrollment and Disenrollment dates are equivalent to Remote Order

Entry System (ROES) dates.

Version 4.0 Page 4 of 21 September 8, 2021

5/19/2021

9/8/2021

4.0

Tables revised. Document completed for inclusion with 2016 Resolicitation

Contract Statement of Work

Final Document submitted for inclusion with 2016 Statement of Work

Final Document for 2022 Solicitation

Added Emergency Classification Reporting – Final document

Reviewers

Name Position

Ellen Hans Home Telehealth Project Manager

Cathy Buck National Lead, RPM-HT

Ron Sandreth

Pam Stressel

James Kircoff

Deputy Director, RPM-HT

Data Analyst, Telehealth Services

HTRE Phase 3 COR

Version 4.0 Page 5 of 21 September 8, 2021

Table of Contents

1 Overview

2 Reporting Process

3 Enrollment and Disenrollment Dates

4 Category of Care and Emergency Management Patient Classification

5 Response Data Elements

6 Listing of all Census Data Elements………………………………………………………………………………………………….9

Table 1: Administrative Data ………………………………………………………………………………………………………………..10

Table 2: Platform Descriptions ……………………………………………………………………………………………………………..14

Table 3: Peripheral Measurements ……………………………………………………………………………………………………….15

Table 4: Disease Management Protocols ………………………………………………………………………………………………16

Table 5: Response Data …………………………………………………………………………………………………………………………17

Appendix A: Disease Management Protocol Conditions ……………………………………………………………………….18

Appendix B: VHA Standardized Disease Management Protocols ……………………………………….………………….20

Version 4.0 Page 6 of 21 September 8, 2021

1 Overview

VA Office of Telehealth Services has been required to report the progress of the Remote Patient

Monitoring -Home Telehealth (RPM-HT) program since October 1, 2005. On a weekly basis, each vendor submits patient specific data that is required to monitor and manage the program. The program office requires this individual patient data to manage the RPM-HT program appropriately - based on accurate and timely census and response reports. A secure transport process is required since individual patient information is included in the report. This report is submitted automatically using an HL7 message.

Once vendors begin submitting a census file for active patients, a validation testing will be coordinated with VA.

This document contains the data collection and reporting requirements for the RPM-HT vendors to submit with the weekly census. For VistA, the HL7 message format and XML document definition are defined in the Home Telehealth HL7 Functions Overview document. The XML load in the HL7 transaction is defined in an appendix of the Home Telehealth HL7 Functions Overview document. The rules describing what will cause an activation rejection in VistA are also detailed in the Home Telehealth HL7

Functions Overview document. For Cerner, this same information is found in the Cerner CareAware

Remote Patient Monitoring Specifications.

2 Reporting Process

The following vendor census reporting process will be used by the vendors and the VA:

• The weekly reports use an automatic HL7 XML reporting mechanism. This reporting process should be completely automatic and not require any manual intervention, except for certain conditions such as resolving errors from a rejected census. The census should be consolidated from all VHA Electronic Health Record systems (EHR) so that one census is submitted to VHA.

• The reports are submitted using a standard HL7 transaction as described further in the HL7

Functions Overview document.

• The 7-day reporting period for all data elements is defined as starting 0:00 Sunday and ending midnight local time on Saturday.

• Vendors need to submit a complete and accurate census report each week no later than 8 am

ET Monday.

• The specific patient level data required includes elements such as: the census file specification version number; patient identification information; VA facility; technology platforms used (such as hub, IVR, App, Browser, Mobile device platform, video hub); the patient’s Category of Care;

and telecommunications used. Additional data includes the current Disease Management

Protocol (DMP) and the assigned measurement types (not values) being collected for the patient

(Temperature, Pulse, Blood Pressure, Weight, Pain, Pulse Oximetry, Peak Flow, and/or Blood

Glucose). The specifics related to this data are listed in Section 6 below.

Version 4.0 Page 7 of 21 September 8, 2021

• The patient identifier is determined by the EHR for which that patient is enrolled. All identifiers that are sent with the patient enrollment via the EHR is what the vendor should send with the census submission (see Table 1).

3 Enrollment and Disenrollment Dates

The ENROLLMENT Date: The Enrollment date is the date on which the patient is established with a vendor server for care. This is reported as a specific date and is a required field. This date is the same as the Service Enrollment Registration date in the Remote Order Entry System (ROES), which is the software ordering package used by the Denver Logistics Center (DLC) - which manages the ordering, distribution, retrieval, refurbishment and logistics for the RPM-HT program.

DISENROLLMENT Date: The Disenrollment date is the same as the Service Disenrollment date in ROES. It is not based upon any other activity performed by the patient or care coordinator (i.e. not due to equipment exchange, non-submittal of data or DMP responses). Once a patient is disenrolled from RPM-

HT, the vendor will not allow the patient to enter or transmit data from the patient’s home telehealth platform after the date of disenrollment.

Manual Entry of Enrollment and Disenrollment Dates for Continuity of Operations:

• The vendor’s Care Coordinator Web View (CCWV) platform needs to have the ability for care coordinators to manually enroll and disenroll Veterans during periods when the EHR is not available for integration.

• This feature would only be available for use (“turned on”) at the request of the Telehealth

Services program office. At all other times, Care Coordinators would not have the ability to enter manually.

• Once interruption with EHR integration is resolved, Care Coordinators would then follow the usual integration process for any manually enrolled or disenrolled Veterans – to ensure all data is accurate between the Care Coordinator Web Viewer (CCWV) and the Veteran’s EHR.

Care Coordinators should be able to manually adjust the enrollment or disenrollment date in the CCWV to match the date of manual entry as needed.

4 Category of Care and Emergency Management Patient Classification

The Category of Care indicator and Emergency Management Patient Classification / Priority Level will be collected for each patient. These fields are to be included in the vendor’s data base and is to be populated in each patient record.

The Category of Care and Emergency Management Patient Classification are mandatory fields and a value shall be entered for each as part of the vendor’s sign-up/ registration process for all new patients.

Version 4.0 Page 8 of 21 September 8, 2021

No default value shall be provided by the user interface. The descriptions of the values shall be easily viewable in the vendor website.

The vendor’s CCWV is required to allow the Care Coordinator to view the existing Category of Care and

Emergency Management Patient Classification and to enter or change the indicator for a currently enrolled patient. A change in the assignment of the Category of Care or Emergency Management

Patient Classification for a patient will not change the enrollment date

5 Response Data Elements

The VA’s expectation is that patients respond to all assigned Disease Management Protocol (DMP) items daily (including any assigned vital signs measurements). This excludes patients in the Low Acuity / Low

Intensity (L2) Category of Care who have a minimum of a once-weekly response requirement. All patients are to be included in response data. The response data elements below will assist VA in calculating and evaluating patient adherence to this expectation for each patient.

The Vendors do not calculate and send a response rate. The Response Rate will be calculated by VA using the three response elements submitted by the vendors: Expected Response Count, Actual

Response Count, and Data Age.

EXPECTED RESPONSE COUNT: The Expected Response Count should usually be reported as 7 days. This can be changed or altered based only on a reduced schedule for expected submissions set by the Care

Coordinator (such as a schedule for 3 days a week, etc.). This data is to be sent in each weekly Census

Report. Although VA will collect this data from the vendor, in most cases VA will use a count of 7 since most RPM-HT patients are expected to respond daily. Low Acuity / Low Intensity (L2) patients are required to respond once weekly, therefore the vendor submitted response count would be the number of days / week that the Care Coordinator has scheduled sessions –with a minimum of 1.

ACTUAL RESPONSE Count: The Actual Response Count provides a count of the number of calendar days during the seven-day week that an enrolled patient submitted a response (as defined below). This data is to be sent in each weekly Census Report. Further clarification points:

1. A response is only counted for the day if the patient provided responses to all DMP and vital sign questions that were assigned to that patient for that day. This means that in order to be counted as responding for the day the patient must submit responses to 100% of questions or measurements they were assigned to complete. In the event a patient is not assigned a vital sign measurement for a particular day, it will still be considered a response if they complete all other questions and measurements. For example, if a diabetic patient is not assigned a blood glucose reading on a certain day, they would be considered a response if they answered all questions and entered all other vital sign measurements without the necessary blood glucose reading.

2. A patient will only have a response counted once daily. If a vendor platform permits patients to submit multiple responses during a calendar day, the information submitted by a patient across multiple sessions occurring within a one calendar day period (24 hours) must be

Version 4.0 Page 9 of 21 September 8, 2021 analyzed to determine if in totality the patient responded to 100% of the assigned questions and measurement data.

3. A patient will not be counted as responding for the day if they only answered some, but not all, of the DMP and vital sign questions that were assigned to the patient. This means that if a patient only answered their vital sign questions for the day or answered a few but not all of the DMP questions, they would not be counted as responding that day.

4. If a vendor device passively connects with the server daily and there is not 100% of the expected patient-entered data present, a patient will not be counted as responding for that day unless they complete the entire session within that day.

Data Age: Data Age is the number of whole days since patient last submitted any data. If a patient has never responded since the enrollment date, this is delineated as NR in the census submission.

Examples:

o if a patient last responded on Saturday (the last day of the reporting period) the data age for that week’s census would be 0.

o If the last day of response was Friday of that week, the data age would be 1.

o If the last day of response was Saturday of the previous week, the data age would be 7 o If it has been 30 days since the patient last responded, the data age would be 30.

o If a patient never responded since enrolled, the data age would be NR

The definitions used by VA Office of Telehealth Services for VA Response Rate Reports (provided here only for vendor information purposes) are:

Responder: Patient answers 100% of assigned questions and measurements each day (24 hours) they are enrolled during the report week. (response rate = 100%)

Partial Responder: Patient does not meet Responder definition but answers some assigned questions and measurements during the report week (response count = 0 < % < 100). Data

Age is < 7 (responded to at least one element during that week).

Non-Responder: Patient does not respond to any of the assigned measurements or questions over the 7-day period (response rate = 0%). The Date Age element is >7

6 Listing of all Census Data Elements

Each patient census record will be built according to the definitions listed below. Each field that is indicated as “Mandatory” (labeled as M in Table 1) shall be included in the reported record unless variances are stated in the field’s description, i.e. disenrollment date does not need to be included until the patient is disenrolled, at which point it shall be included. In addition, some elements are required to be Validated (labeled as V in Table 1).

Version 4.0 Page 10 of 21 September 8, 2021

As noted in the Tables below, for some data items, vendors will be provided the exact name / format to use in order to ensure census accuracy. The vendor’s use of the correct name will be verified during validation processes.

The HL7 Census message is built and sent to the VA Census HL7 server as defined in the Home

Telehealth HL7 Functions Overview document. The Census results are communicated to the VA with an

MDM-T02 HL7 transaction. The Census results are to be formatted as and XML file (text string) within the text field of the OBX segment of the HL7 message. It will include patient identification information, VA facility identification information, enrollment and disenrollment dates, and basic information listing the platforms currently being used to support the Veteran.

Table 1: Administrative Data

Data item

M an d at o ry

Description Example

Census Version MV The census file specification version of the patient data items definition; the expected version is the one for this document.

(Provided by

Telehealth

Services)

Vendor facility number

MV The unique VA identifier for the Telehealth vendor sending the survey results. It is found in the Home

Telehealth HL7 Functions Overview document

(Provided by

Telehealth

Services)

Vendor name MV The name of the Telehealth vendor sending the survey results. It is found in the Home Telehealth HL7

Functions Overview document.

(Provided by

Telehealth

Services)

Submission date and time

MV Date and time that the census was submitted As per XML standards

Report period start date

MV Start date for the reporting period being submitted

(Sunday)

As per XML standards

Report period end date

MV End date for the reporting period being submitted

(midnight Saturday)

As per XML standards

1 M indicates that the data entry is mandatory; however, the contents will not be validated. The census submission will be rejected if the data item is not present in the submission. V means the data is not mandatory, but if entered will be validated against database formatting and structure rules (i.e. date fields must have valid dates, number fields must only contain numbers, and some fields must follow a valid pattern). If the element does not meet the format for the identifier, the census will be rejected. MV indicates that the data entry is mandatory and must meet the validation criteria; otherwise, the census submission will be rejected.

Version 4.0 Page 11 of 21 September 8, 2021

M an d at o

Patient SSN

(If available)

V Social security number of patient As defined in

HL7 document

Patient ICN MV Integration Control Number of patient. The ICN is the

VA enterprise patient identifier; it links the RPM-HT patient data to other medical records stored within any other VHA medical system.

As defined in the HL7 document

Patient vendor

DFN

MV Data File Number. Vendor Medical Record number

(MRN). Each patient will have only one vendor MRN.

Within a vendor’s system, this identifier shall be a unique number for a patient across all accounts and all facilities. One patient can have multiple enrollment episodes in a vendor’s system to include enrollment episodes during which the DMP, facility number, or any other data element may change, but must only have one medical record number in the

Vendor’s system

As defined by vendor

Patient EDIPI

(if available)

V Electronic Data Interchange Personal Identifier. This is a 10-digit numerical unique patient identifier.

Provided by VA during EHR integration

Patient’s servicing facility

MV The unique VA facility identifier for the sign-up medical facility found in the Facility Data tab of the

Weekly Activity Reporting spreadsheet

As described in the HL7

Functions

Overview document

Patient’s first name

M Patient first name. The patient’s first name may be null (blank). The patient’s first name must match the patient’s EHR

As described in the HL7Funtions

Overview document

Patient’s middle name

M Patient middle name or initial. The patient’s middle name or initial may be null (blank). The patient’s middle name or initial must match EHR.

As described in the HL7Funtions

Overview document

Patient’s last name

M Patient last name. The patient’s middle name or initial must match EHR

As described in the HL7Funtions

Version 4.0 Page 12 of 21 September 8, 2021

M an d at o

Overview document

Patient’s DOB MV Patient date of birth. The patient’s DOB must match

EHR

As described HL7

Functions

Overview document

Patient’s

Category of Care

MV Category of Care indicating the intensity of care required to monitor the patient’s condition. This field is a mandatory field that is required to be entered as part of the enrollment process for all new patients.

No default value shall be provided by the user interface. The enrollment will not continue if the care coordinator fails to select a Category of Care

Non -Institutional Care (NIC) 1

Chronic Care Management (CCM) 2

Acute Care Management (ACM) 3

Health Promotion / Disease Prevention 4

Low Acuity / Low Intensity (L2) 5

Non-Institutional Care Non-Responder (NICLR) 6

Unknown (Not assigned) 7

1-7

Emergency

Management

Classification

MV The Emergency Management Patient

Classification/Priority Level is assigned by the Care

Coordinator on Enrollment and is a mandatory field.

The classification level can by updated by the Care

Coordinator based on any changes in the patient’s condition. These are described in detail in the RPM-

HT Operations Manual

Level 1 – High Priority 1

Version 4.0 Page 13 of 21 September 8, 2021

M an d at o

Level 2 – Moderate Priority 2

Level 3 – Low Priority 3

Unknown / not assigned 4

Patient’s enrollment date

MV Date patient enrolled in the RPM-HT program (same as ROES enrollment date)

As described HL7

Functions

Overview document

Patient’s disenrollment date

MV Date patient disenrolled from the RPM-HT program.

This is blank until the patient is disenrolled (same as

ROES disenrollment date)

As described HL7

Functions

Overview document

Patient’s EHR activation date

MV Date patient was last activated via EHR for services As described in

HL7 Functions

Overview document

Patient’s EHR inactivation date

MV Date patient was last inactivated via EHR for services As described in

HL7 Functions

Overview document

Care Coordinator

Identifier

MV The Care Coordinator Identifier is provided via the integration with the EHR. For VistA, that is the DUZ for the Care coordinator currently associated with the patient. The DUZ is entered manually by the Care

Coordinator with vendor website registration.

Vendors must verify any mismatched DUZ numbers

(e.g. the number sent with integration does not match any Care Coordinators that have registered in the vendor website) and resolve before census submission.

For Cerner, the Electronic Data Interchange Personal

Identifier (EDIPI) is sent via the EHR integration. This is a 10-digit unique Care Coordinator identifier. The

EDIPI is entered manually by the Care Coordinator with vendor website registration. Vendors must verify any mismatched DUZ numbers (e.g. the number sent

Blank until the patient record is linked using EHR

Provided by VA during EHR integration

Version 4.0 Page 14 of 21 September 8, 2021

M an d at o with integration does not match any Care

Coordinators that have registered in the vendor website) and resolved before census submission

Care

Coordinator’s first name

MV Care Coordinator’s first name. The first name may be null (blank).

Blank until the patient record is linked using EHR

Integration.

Care

Coordinator’s middle name

MV Care Coordinator’s middle name or initial. The middle name or initial may be null (blank).

Blank until the patient record is linked using EHR

Integration.

Care

Coordinator’s last name

MV Care Coordinator’s last name. Blank until the patient record is linked using EHR

Integration.

Care

Coordinator’s home facility

MV The unique VA facility identifier for the Care

Coordinator’s home facility.

Blank until the patient record is linked using EHR

Integration.

Table 2: Platform Descriptions (one platform must be submitted with census)

M an d at o

Hub device

(if awarded)

V The patient is using a vendor supplied hub unit.

The vendor’s device model name is to be labelled as listed in ROES.

IVR

(if awarded)

V The patient uses

Interactive Voice Response

(IVR) technology.

The vendor’s IVR name is to be labelled as listed in ROES

Version 4.0 Page 15 of 21 September 8, 2021

M an d at

App

(if awarded)

V The Patient uses the vendor’s mobile application via a Veteran-owned or VA-provided device

The vendor’s app name is to be labelled as listed in ROES

Browser

(if awarded)

V The patient uses vendor provided web browser.

The vendor’s browser name is to be labelled as listed in ROES

Video Hub

(if awarded)

V The patient uses a video hub technology that connects via WIFI / cellular

The vendor’s video hub name is to be labelled as listed in ROES

Mobile

Device

Platform

(if awarded)

V The patient uses the vendor’s mobile device platform that connects via cellular

The vendor’s mobile device name is to be labelled as listed in ROES

Table 3: Peripheral Measurements

M an d at

Measurement V

The biometric measurement assigned by the Care Coordinator for the patient. This could be manual (self-reported) or from a peripheral.

Peripheral measurements could be wired, wireless, or integrated in a hub device.

For the following measurements listed below, use the following codes as a suffix.

If there is more than one method of collection for a measurement, use the primary / most used method

Manual: M

Peripheral:

Wired W

Wireless S

Integrated I

Blood Pressure (BP) BPM, BPW, BPS, BPI

Version 4.0 Page 16 of 21 September 8, 2021

M an d at

Heart Rate (HR) HRM, HRW, HRS, HRI

Weight (W) WM, WPW, WS, WI

Blood Glucose (BG) BGM, BGW, BGS, BGI

Pulse Oximeter (PO) POM, POW, POS, POI

Peak Flow (PF) PFM, PFW, PFS, PFI

Temperature (T) TM, TW, TS, TI

Steps (S) SM, SW, SS, SI

Table 4: Disease Management Protocols

M an d at

DMP Title MV The Standard name of the

DMP that is currently assigned to the patient. If the patient is assigned more than one DMP (co-morbid, tri-morbid, etc.)

all would be submitted.

Appendix A and B

Version 4.0 Page 17 of 21 September 8, 2021

Table 5: Response Data

Data item

M an d at response count

MV Count of days in the week when the Patient responded 100% to all assigned questions and measurements (within the 24-hour period)

5, 2, 0 expected response count

MV Count of days in the week when the Patient was expected to respond as assigned by the Care Coordinator

7, 3, 1

Patient’s data age

MV Number of whole days since Patient last submitted any data.

If a patient has Never Responded since enrollment date, enter NR

0, 1, 5, 40, NR

Version 4.0 Page 18 of 21 September 8, 2021

Appendix A

DMP Vendor Title Nomenclature

Vendor titles below are to be used as part of vendor DMP title which helps VA to capture

DMP under appropriate “condition” for VA data analysis

DMP Vendor Title Description

No DMP Recorded For patients with no assigned DMP

Anxiety Anxiety

Asthma Asthma

Bipolar Bipolar Disorder

CAD Coronary Artery Disease

Cancer Cancer Care

CHF or HF Congestive Heart failure, Heart Failure

CKD Chronic Kidney Disease

Coag Anticoagulant Therapy Monitoring

COPD Chronic Obstructive Pulmonary Disease

Dementia Dementia

Depression Depression; Depressive Disorder

DM Diabetes Mellitus

HepC Viral Hepatitis C

HIV Human Immunodeficiency Virus infection

Homeless Homeless Veterans

HPL Hyperlipidemia

HTN Hypertension; Hypertensive Disorder

Infectious Infectious Illness

Low ADL (LAMP) Difficulty performing personal care activities

MI Myocardial Infarction

MS Multiple Sclerosis

Pain Pain; Pain Management

Version 4.0 Page 19 of 21 September 8, 2021

DMP Vendor Title Description

Palliative Care Palliative Care

Pneumonia Pneumonia (separate from Infectious Illness)

Polypharmacy Polypharmacy

Post-Hospital Post Hospital Discharge

Prediabetes Pre-Diabetes / Impaired Glucose Tolerance

Psychosis Psychosis

PTSD Post-Traumatic Stress Disorder

Schiz Schizophrenia

Sleep Apnea Sleep Apnea

Tobacco Cessation Tobacco Cessation

Stroke Cerebrovascular Accident

Wound Pressure Ulcers; Arterial Ulcers; Venous Stasis Ulcers; DM Ulcers

Version 4.0 Page 20 of 21 September 8, 2021

APPENDIX B

VHA Standardized DMPs

Each title below will include suffix with 2-digit month, 2-digit date, and 2-digit year of current version – e.g. VHA-Bipolar Disorder 092520 (dates will be provided by VA)

VHA DMP Title Description

VHA- Bipolar Disorder Standardized VHA DMP for Bipolar Disorder

VHA-Cirrhosis Standardized VHA DMP for Cirrhosis

VHA-CKD Standardized VHA DMP for Chronic Kidney Disease

VHA-COPD Standardized VHA DMP for Chronic Obstructive Pulmonary Disease

VHA-Dementia Standardized VHA DMP for Dementia

VHA-Depression Standardized VHA DMP for Depression

VHA-DM Standardized VHA DMP for Diabetes Mellitus

VHA-Heart Failure Standardized VHA DMP for Heart Failure

VHA-HTN Standardized VHA DMP for Hypertension and Hypertensive Disorder

VHA-Infectious Illness Standardized VHA DMP for Infectious Illness (e.g. COVID, Influenza)

VHA-LAMP Standardized VHA DMP for Low ADL Monitoring Program

VHA-MS Standardized VHA DMP for Multiple Sclerosis

VHA-Pain Standardized VHA DMP for Pain Management

VHA-Palliative Care Standardized VHA DMP for Palliative Care

VHA Post-COVID Symptoms Standardized VHA DMP for Post-COVID Symptoms

VHA-Psychosis Standardized VHA DMP for Psychotic Disorder

VHA-PTSD Standardized VHA DMP for Post-Traumatic Stress Disorder

VHA Stable & Able Standardized VHA DMP for Homeless Veterans

Version 4.0 Page 21 of 21 September 8, 2021

VHA-SUD Standardized VHA DMP for Substance Use Disorder

VHA-Tobacco Cessation Standardized VHA DMP for Tobacco Cessation

VHA Wound Care Standardized VHA DMP for Wound Care

VHA-Weight Management Standardized VHA DMP for Weight Management

VHA-L2 HTN Standardized VHA DMP for Low Acuity / Low Intensity Hypertension

VHA-L2 Pre-Diabetes Standardized VHA DMP for Low Acuity / Low Intensity Early Diabetes

VHA-L2 Diabetes Standardized VHA DMP for Low Acuity / Low Intensity Diabetes

VHA-L2 Depression Standardized VHA DMP for Low Acuity / Low Intensity Depression

VHA-L2 Heart Failure Standardized VHA DMP for early onset / maintenance Heart Failure

VHA-L2 Tobacco Cessation Standardized VHA DMP for Low Acuity / Low Intensity Tobacco

Cessation

VHA-L2 Weight Management Standardized VHA DMP for Low Acuity / Low Intensity Weight

Management

Home Telehealth Reporting (HTR)

Quality Improvement Reports (QIR) User Manual

September 2020 Version 6.0

Department of Veterans Affairs (VA)

Attachment W

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, please address only one vendor in any (each) QIR.

QIR OVERVIEW

A feature of Integrated Home Telehealth Application (IHTA) is the ability to enter and track Quality Improvement Reports (QIR) for quality and patient safety issues related to Home Telehealth devices.

NOTE: Access to the functionality within each module is restricted by the user roles and permissions granted during the registration approval process; therefore, you may not have access to all of the functionality described in this help file.

The steps below outline the basic QIR workflow. Within each step, there may be times where users will deviate from the workflow to request additional information, add additional comments, or add an attachment. Refer to the links referenced in each step for more information.

If the Originator determines that a quality or patient safety issue qualifies for a QIR, the Originator Creates and Submits a New QIR . The status of the QIR is "New" and it advances to the National Administrator.

1.

The National Administrator reviews the QIR for completeness, selects the required data from the DMP fields, and approves the QIR. (See National Administrator Approval .) The status of the QIR is "Approved" and it advances to the Vendor for a response.

2.

The Vendor Replies to the QIR . The status of the QIR is "Replied" and it advances to the Originator.

3.

NOTE: The Vendor has ten (10) business days (excluding holidays) to reply. After ten (10) business days, if there is no response from the Vendor, the application automatically generates an e-mail indicating that a response is required.

The Originator reviews the Vendor's response and agrees with the response. (Refer to Originator Response to Vendor .)

4.

The National Administrator reviews the Vendor's response and the Originator's comments and closes the QIR. (Refer to National Administrator Closes QIR .)

5.

NOTE: When a step in the QIR workflow is completed by the responsible participant, the application automatically generates an e-mail to all participants indicating an update to the QIR was made.

See Also QIR Buttons

QIR Participants QIR Statuses When to Use the Update Button

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, QIR PARTICIPANTS

The following table outlines the four participants active in the QIR workflow:

Participant Description

Originator

An individual who monitors quality and patient safety issues related to Home Telehealth (HT) devices. Anyone who creates and submits a new QIR is considered the Originator. QIRs submitted by the Originator may be edited by using View My or by Search All. This is the only role that can withdraw a QIR (see Originator Withdraws New QIR).

Contract Office The Contract Office for the Office of Telehealth Services (OTS) HT Program. These users may view all QIRs, except for those with a status of "New", in the application at any time. Access is limited to view only.

National Administrator

An individual in the OTS HT Program who is responsible for approving all QIR submissions. The National Administrator reviews the Recommendations and Remarks made by the Originator and the responses provided by the Vendor. The National Administrator is the only participant who can close a QIR.

Vendor An authorized representative for a supplier of HT equipment. Each Vendor is limited to accessing, responding to, and viewing ONLY THOSE QIRs related to the devices supplied by the associated company.

NOTE: All participants (except Vendors) may view any QIR in the application at any time by using the Search All feature.

QIR Overview QIR Buttons QIR Statuses QIR Tabs

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, QIR TABS

After a QIR has been submitted, the QIR displays four tabs for review and update: Summary , Recommendations and Remarks , Vendor Actions , and Attachments . The following table outlines the content and purpose of each tab.

Tab Description

Summary

Provides the Status , Tracking Number (TN), Headline (subject of QIR) , Submitted Date, Submitted By, Facility (initiating the QIR) , Vendor, Type of Complaint , DMP Issue , DMP Issue Type , Contract or Purchase Order Number , Device Model , Serial Number , and Cause of Complaint fields. Headline , Vendor , Cause of Complaint, and Recommendations and Remarks are required fields when the QIR is submitted.

The Originator can update the Cause of Complaint field on the Summary tab once the QIR has been submitted, but before the National Administrator approves the QIR, by adding text and then clicking Update .

Recommendations and Remarks

Recommendations and Remarks : The issuing Facility # and name are entered into this field upon creation. The Originator and the National Administrator also use this field to enter comments in the QIR or to request additional information. This field is not active for the Vendor (see the Vendor Actions tab below).

Recommendations and Remarks History : Participants use this field to review Originator and National Administrator responses, comments, and requests. This field displays all prior text entered in the Recommendations and Remarks field with the timestamp and User Name.

Vendor Actions

Vendor Response Due: After a QIR has been approved by the National Administrator, the Vendor has ten business days to provide a solution to the QIR. This date will remain active until the Vendor enters a response and clicks the Reply button. This date appears just below the tabs display on the Vendor Actions tab. The Vendor Response Due will recalculate and re-display whenever the National Administrator updates the QIR.

Vendor Actions : The Vendor uses this field to request additional information or to enter a solution to the QIR. This field is only active for the Vendor.

Vendor Actions History : Participants use this tab to review Vendor responses, comments, and requests. This field displays all prior text entered in the Vendor Actions field and the timestamp and User Name.

Attachments All active participants will use this tab to upload attachments. (See Add or Remove Attachments .)

QIR Participants QIR Buttons

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, QIR BUTTONS

The following table describes the buttons used in the QIR Workflow.

NOTE: Some of the buttons below will only be active based on a user's assigned application role and the status of the QIR (refer to QIR Overview and QIR Statuses ).

Button Role Purpose Status Changes:

From To

All (except the Contract

Office) Uploads an attachment to a QIR. N/A N/A

Originator Indicates that the Originator agrees with the Vendor's response.

Replied Agreed

National Administrator

Indicates that the National Administrator approves the QIR and advances it to the Vendor.

New Approved

All

This button may be used at anytime during the QIR process.

When editing a QIR, a dialog box displays indicating that data (currently entered) will be lost if the window closes.

When on the View My or Search All windows, the window will close because no data has been entered.

N/A N/A

National Administrator

Completes the QIR. Once the National Administrator determines that the resolution discussed in the QIR is satisfactory, the QIR is considered resolved.

If an Originator decides to withdraw a QIR after it has been approved, the National Administrator uses the Close button to close a QIR, in effect making the QIR inactive.

Agreed, Replied, or Approved

Closed

All (except for When a QIR is selected from the QIR ▪ N/A N/A the Contract Office) table by a participant, the Edit button displays.

Participants use the Edit button to open a QIR to modify it.

National Administrator

Export a list of QIRs to an Excel spreadsheet from the Search All QIRs window.

N/A N/A

All Users who can access a QIR use the PDF button to view and print a QIR in the PDF format of the VA Form 0729.

N/A N/A

All Refreshes the View All and Search All tables with most current QIR data.

N/A N/A

All (except the Contract

Office)

Deletes an attachment from a QIR. A dialog box displays to ensure this is the action to take.

N/A N/A

Vendor

Responds to the initial Cause of Complaint and any Recommendations and Remarks entered by the Originator or National Administrator.

Clicking this button satisfies the Vendor Response Due reminder.

Approved Replied

All Restores the fields on the Search All window to their original state before editing.

N/A N/A

Originator, National

Administrator, Vendor

To request additional information, submit additional information in the Recommendations and Remarks or Vendor Response fields, and to add an attachment.

(See When to Use the Update Button .)

N/A

NOTE:

Clicking the Update button does not change the status of the

QIR.

N/A

NOTE:

Clicking the Update button does not change the status of the QIR.

All

Allows a user to view a closed or withdrawn QIR with a status of "Closed" or "Withdrawn".

Allows a user to read a QIR in which s/he was not a participant.

Allows a user to examine an attachment that was added to a QIR.

N/A N/A

Originator

Takes the QIR out of the “New” status.▪ The status, "Withdrawn", indicates that the QIR is no longer active and is no longer available for input by any of the participants.

New Withdrawn

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, WHEN TO USE THE UPDATE BUTTON

In addition to the QIR workflow described in QIR Overview , the QIR functionality was also designed to allow for open communication between the Originator, Vendor, and National Administrator.

Throughout the QIR workflow, the National Administrator, Originator, and Vendor use the Update button to submit Recommendations and Remarks , add attachments, and/or to request or provide additional information on the Recommendations and Remarks or Vendor Actions tabs.

Below are some sample scenarios for when it is appropriate to use the Update button:

National Administrator requires additional information from the Originator. The request is entered in the Recommendations and Remarks field and the National Administrator clicks Update . This request may also trigger the Vendor Response Due .

Vendor requires additional information from the Originator or National Administrator. The request is entered in the Vendor Actions field and the Vendor clicks Update .

Originator requires additional information from the Vendor. The request is entered in the Recommendations and Remarks field and the Originator clicks Update.

National Administrator requires additional information from the Vendor. The request is entered in the Recommendations and Remarks field and the National Administrator clicks Update .

Add or remove an attachment. Add the attachment by clicking the Add button and selecting the attachment using the browser. Remove the attachment by selecting an attachment from the Attachment table, and click the Remove button. In either instance, after completing the add or remove action, click Update .

NOTE: Clicking the Update button does not change the status of the QIR. Also, it does not stop the Vendor Response Due clock for the due date.

National Administrator Approval Vendor Replies to QIR Originator Response to Vendor National Administrator Closes QIR Add or Remove Attachments

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, QIR STATUSES

The following table identifies the various QIR statuses used in the automated QIR workflow. A user may search by status when using the Search All feature or when searching by Status on the View My window.

Status Description

Agreed The status of the QIR when the Originator concurs with the Vendor response.

Approved The status of the QIR after the National Administrator has concurred with the Originator's submitted QIR. It advances to the Vendor.

The status remains "Approved" until the Vendor clicks Reply .▪

Closed The status of the QIR when the National Administrator finds the Vendor's and Originator's recommendations/solutions acceptable and consequently considers the QIR resolved.

New

The status of the QIR when first submitted by the Originator.▪ The status remains "New" until the National Administrator has approved the QIR. Once approved, the QIR advances to the Vendor for response.

Replied The status of the QIR after the Vendor has clicked Reply .▪ The continued status of the QIR until the Originator agrees with the Vendor's response or until the National Administrator closes the QIR.

Withdrawn

The status of the QIR when the Originator pulls the QIR from submittal. Withdrawn status is not applicable if the QIR has been approved.

The QIR may only be pulled when it is in the “New” status. ▪

QIR Participants QIR Tabs QIR Buttons

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, ORIGINATOR CREATES AND SUBMITS NEW QIR

Participant : Originator Action : Submit New QIR

If the Originator determines that an unresolved quality or patient safety issue qualifies for a QIR, the Originator submits a new QIR by completing the following steps:

Select Manage QIRs > New . The New QIR window displays.1.

The following fields are required to submit a new QIR:2.

Headline : Use this field to provide a brief description of the QIR for easy identification later.

Facility: Select the facility that is initiating the QIR from the drop-down menu. ▪

NOTE: The facility selected in this drop-down menu is the facility initiating the QIR. This could be the Originator's assigned facility or another facility within the Originator's VISN.

Vendor: Select the appropriate Vendor from the drop-down list provided.▪

NOTE: Verify that you have selected the correct Vendor. This is an important step in ensuring that the submitted quality or patient safety issue is being viewed by the appropriate Vendor.

Cause of Complaint : Enter information regarding the issue or problem. The information provided should be enough detail for a clear understanding of the issue or problem. This field can be updated later on the Summary tab after the QIR is submitted, but before the National Administrator approves the QIR.

Recommendations and Remarks : Enter any other recommendations or additional remarks about the complaint/device/issue in the field provided.

NOTE: Originators are also required to enter the following text in the Recommendations and Remarks field: <Facility Number> <Facility Name>; for example, 605 Loma Linda VAMC. This is the same facility selected in the Facility field on the New QIR window.

Alternatively, you can copy (Ctrl+C) and paste (Ctrl+V) the facility # and name from the Facility drop-down menu to the Recommendations and Remarks field.

Additional information can be added to the QIR (if known), including the following:

Type of Complaint : Select the Type of Complaint (i.e., New Item, Quality Complaint, and Similar Item). The Type of Complaint field is derived from the legacy QIR form.

Contract or Purchase Order Number : Enter alpha-numeric characters of the Contract ▪ or Purchase Order Number in the field provided.

Device Model : Select the Device Model from the drop-down list. When this item is chosen before selecting a Vendor, the application will automatically populate the associated Vendor field.

Serial Number : Enter alpha-numeric characters for the Serial Number when the QIR is for a specific device.

Attachment : If a document or graphic can provide additional information, add the document or graphic as additional reference material for the QIR. An attachment may be added at any time when the QIR is available for editing. (Refer to Add or Remove Attachments .)

Once all required information has been entered, click Submit .3.

An Information Message will display indicating that the new QIR was created successfully.

The New QIR window will be blank for submitting another QIR. Click Cancel to close this screen.

4.

The application generates an e-mail indicating that a new QIR was submitted. The status of this QIR is "New" and it is assigned a Tracking Number (TN).

5.

Originator Withdraws New QIR

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, ORIGINATOR WITHDRAWS NEW QIR

Participant : Originator Action : Withdraws New QIR

If the Originator determines that a newly submitted QIR is no longer needed or if there is any other reason for making the QIR inactive, the QIR may be withdrawn from submittal. As long as the National Administrator has not approved the QIR, the QIR can be withdrawn. Once a QIR is approved, the QIR continues through the process; however, the Originator may request that the National Administrator close the QIR if it is no longer viable.

Select Manage QIRs > View My. 1.

Locate the QIR and click once in the QIR row (the row will be highlighted and buttons will appear at the bottom of the table, including Edit).

2.

Click Edit to open the QIR.3.

Select the Recommendations and Remarks tab.4.

Enter the reason for withdrawing the QIR in the Recommendations and Remarks field and then click Withdraw . The QIR's status must be “New” for the Withdraw button to display.

5.

A dialog box displays indicating that the QIR will no longer be available for processing and whether or not to continue with the action. Click Yes .

6.

The status of the QIR changes to “Withdrawn” and the application generates an e-mail indicating that the status has changed.

7.

Once the QIR is withdrawn, it no longer appears in the list of active QIRs. To locate this QIR for future viewing, go to Manage QIRs > Search All. Select "Withdrawn" from the Status drop-down menu and click Search .

Originator Creates & Submits New QIR

NOTE: Do NOT enter any Personally Identifiable Information (PII) into the IHTA system! In addition, NATIONAL ADMINISTRATOR APPROVAL

Participant : National Administrator Action : Approval of QIR for Advancing to Vendor for Response

Once a new QIR has been submitted, the National Administrator reviews the QIR for completeness, adds recommendations and remarks, and may request additional information.

Once the QIR is considered satisfactory, the National Administrator approves the QIR to advance to the Vendor for a response:

Locate the QIR using the Tracking Number (TN) found in the e-mail notification. Click once in the QIR row (the row will be highlighted and buttons will appear at the bottom of the table, including Edit).

1.

Click Edit .2.

Before a QIR can be approved by a National Administrator, two fields must be completed on the Summary tab:

DMP Issue : Select "Yes" or "No" to indicate whether or not this QIR is related to an issue with a Disease Management Protocol (DMP) currently being used in the field.

DMP Issue Type : If "Yes" is selected for DMP Issue , select the DMP Issue Type (ie, Unknown, VHA DMP, Vendor DMP) from the drop-down menu for this field.

3.

Select the Summary tab and then select the appropriate response to…