IHERO UseCase 2010 ROPP

This template is for one or two page IHE workitem proposals for initial review.

<Delete everything in italics and angle brackets and replace with real text>

1. Proposed Workitem: Radiation Oncology Patient Portal (ROPP)

Proposal Editor: D. Armstrong (detarmstrong@visiontree.com), A. Da Costa (adacosta@visiontree.com), M. Pellinat (mpellinat@visiontree.com)
Editor: F. Swerdloff
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: Radiation Oncology

2. The Problem

Radiation Oncology patients typically do not have the ability to easily view their schedule, treatment outline/prescriptions, results, QA performed on the patient’s behalf, etc., since this data resides on clinical systems to which the patient has no access. In addition, patients generate their own data, such as QoL (Quality of Life) assessments, which then have to be either coded and hand entered into the TMS/OIS or scanned and imported as either PDF or DICOM secondary capture. The Treatment Course for the patient typically includes a variety of forms that the patient needs to fill out during various times.

Patients need to be able to view their demographic information and treatment schedule, as well as some way of submitting change requests to either one.

Patients are empowered, when given the ability to view their own clinical information including diagnosis, procedure, toxicities, dose, tumor volume, medications, allergies, etc. The sense of involvement in their own treatment is thought to improve overall outcome.

A patient’s coordinated care team can also be more involved in their care through quality alerts triggered by roles, metrics, tasks and form completion. Real-time aggregate quality data collected on a patient, site and population health level are necessary for quality care and treatment.

3. Key Use Case

The Patient Portal provides a patient with authenticated and authorized access to a set of patient specific reports and alerts for Meaningful Use [link to glossary]. This actor (the Patient Portal) isolates the rest of the clinical environment from access by the patient by negotiating of all HIPAA requirements related to internal authorization and authentication concerns. At the same time, clinical staff will use the portal to access an appropriate subset of data, alerts and real time quality metrics, depending on their role (i.e. physician, researcher, nurse, etc.).

A patient can login to the portal from a computer outside the enterprise. Patients can complete QoL assessments in their secure portal. Assessments can be delivered at specified time points (i.e. pre-treatment, 3 month, 6 month, 12 month, etc) along with corresponding email/SMS text reminders managed on both site and admin-levels. Patients can provide registration and health history information using the portal.

Patient supplied information must propagate from the Patient Portal to those systems responsible for maintaining that information. This is typically mediated by staff interacting with the Patient Portal.

Information to be supplied to the patient must be transferred from those systems responsible for maintaining information. Existing clinical implementations use bi-directional data exchange that may be triggered by configurable data elements and their values. The data interchange between clinical systems will occur via a simple, application agnostic transport framework, connecting with a secure, modular, interoperable patient portal.

While it is possibly outside the scope of IHE, the application providing Patient Portal capabilities should also be responsible for enabling:

• Pharmacy, Lab Results, Procedure Eligibility data access, as well as payment capability.

• Download educational materials (outside IHE environment)

• Visibility of appropriate ongoing clinical trials, clinical trial matching (outside IHE environment)

• Connectivity to remote/home monitoring systems. Reminders, messages and forms are triggered based on data values. Data analysis and trends can be graphed on the medical team side, patient-level reporting (outside IHE environment)

4. Standards & Systems

RT-EMR, TMS, RIS, HIS, OIS, RT-PACS

Possible actors: Scheduler, Results Manager, Prescription Manager, QA Manager

DICOM, CCD, CCR, HL7

5. Discussion

The Patient Portal Actor has two primary user types, Patient and Staff (all clinical team members). Some of the key user actions that will need to be supported include (CRUD – Create, Read, Update, Delete):

Patient:

• Read / Update / Delete - patient demographics

• Read / Update - patient’s schedule

• Read - patient level clinical data: diagnosis, tumor site, toxicity, tumor volume, treatment type

• Create / Update / Delete - Consent for permission to data collection, participation in clinical trial and propagation to other relevant clinical systems

• Create - Self-reported Data: QoL assessments, health history

• Read / Update – patient appointment

• Read / Update - Request Refill of prescriptions

• Read - Patient & Medical Team Alerts, triggered by demographic data and patient reported adverse events tracking

Staff:

Based on a user’s role (i.e. physician, researcher, nurse, or other medical team member

• Patient account management (creation, access, etc.)

• Update patient portal data (i.e. schedule modifications, medications/refills based on patient request)

• Set patient specific alerts

• Read / Respond to patient specific alerts

• Quality alerts are triggered by roles, metrics, tasks and form completion & outcomes data collection, messaging are necessary for quality care and treatment

• Generate quality metrics reports, including identifying QA performed on behalf of patient, e.g. IMRT QA or lack thereof and real-time national quality benchmark data