Difference between revisions of "IHERO UseCase 2010 ROPP"
FridaSJSTS (talk | contribs) |
FridaSJSTS (talk | contribs) |
||
Line 43: | Line 43: | ||
==4. Standards & Systems== | ==4. Standards & Systems== | ||
− | + | <List existing systems that are/could be involved in the problem/solution.> | |
− | + | RT-EMR, TMS, RIS, HIS, OIS, RT-PACS | |
− | + | Possible actors: Scheduler, Results Manager, Prescription Manager, QA Manager | |
− | + | <If known, list standards which might be relevant to the solution> | |
+ | DICOM, CCD, CCR, HL7 | ||
==5. Discussion== | ==5. Discussion== |
Revision as of 19:11, 10 March 2010
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
<List existing systems that are/could be involved in the problem/solution.> RT-EMR, TMS, RIS, HIS, OIS, RT-PACS Possible actors: Scheduler, Results Manager, Prescription Manager, QA Manager <If known, list standards which might be relevant to the solution> DICOM, CCD, CCR, HL7
5. Discussion
<Include additional discussion or consider a few details which might be useful for the detailed proposal>
- <Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>
- <What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>
- <What are some of the risks or open issues to be addressed?>
<This is the brief proposal. Try to keep it to 1 or at most 2 pages>