Radiation Oncology Workflow Exchange with HIS

1. Proposed Workitem: Radiation Oncology Workflow Exchange with HIS

• Proposal Editor: Sam Brain
• Editor: Sam Brain
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiation Oncology

2. The Problem

This use case addresses three areas where problems arise because of lack of information exchange between the Radiation Oncology Information System (ROIS) and the Hospital Information System (HIS). The data flows in question are:

(1) Inbound Patient Registration or Demographics information (ADT)

(2) Outbound Billing information

(3) Outbound Radiation Oncology scheduling and treatment summary.

3. Key Use Case

How it currently works:

1. Patient registration and demographics information.

During the Radiation Oncology clinical process, clinical staff typically enter patient registration and demographic data multiple times. For example: into the ROIS at the patient's initial visit to the Radiation Oncology department; at the imaging modality; at the treatment planning workstation.

The patient information is often read manually from patient information displayed by the HIS application, and then typed into the Radiation Oncology application(s), a time-consuming and error-prone process.

In addition, if any of the patient's information changes in the HIS (for instance, medical record number, family name), there is no well-defined mechanism for propagating those changes to the ROIS. There is the Patient Information Reconciliation Profile in IHE Radiology which performs the changes in the information of the Patient on the above circumstances.

2. Billing.

Billing information is often generated when scheduled procedures are manually or automatically completed, for example at modality, simulator, or accelerator. The billing information is stored in the Archive.

The billing staff extract this billing information from the Archive, review it for accuracy, and enter it manually into the Hospital Billing system.

This method of manual data entry is error-prone and such errors can lead to loss of revenue or might cause the claim to be queried or refused by the medical insurance provider.

3. Radiation Oncology schedule, and Treatment summary.

The schedule of Radiation Oncology treatments reside only in the ROIS, and are not available to other clinics in the hospital. This can lead to scheduling conflicts if a Radiation Oncology patient has appointments in other clinics as well as Radiation Oncology clinic.

In addition, it would be of use if some summary information about the radiation treatments was available in other clinics, in order that clinical staff be aware of any radiation-related issues to be considered in treating the patient.

This would be particularly true if a current or previous radiation oncology patient suffered trauma and was admitted to the ER. Access to all aspects of the patient's medical history, including radiation treatments, would be crucial to diagnosis and treatment of such a case.

How it should work:

<In this discussion, the "ROIS" is a little vague, and probably means multiple agents, depending on the scenario number, 1, 2 or 3. >

Most of the interaction between the ROIS and HIS is expected to use the HL7 protocol Version 2.

1. Patient registration and demographics information.

To keep the discussion simple, we assumed that the patient registration and demographics entered into the HIS before the patient is registered in the ROIS.

The first time the ROIS is queried for the patient's information (typically on the patient's initial visit to the Rad Onc clinic) it is found not to exist in the Archive. This triggers an HL7 query, either to the HIS if it supports a query/retrieve model, or to an (as-yet undefined) Actor, an "HL7 archiver", whose function is to listen to the HL7 ADT broadcast traffic directed to it, and store it in medium-term storage.

Either the HIS HL7 server, or the "HL7 Archiver" would respond to the HL7 query/retrieve and supply the patient registration and demographics to the ROIS, which would then store the data in the Archive.

Any changes which occur to patient registration and demographics data in the HIS triggers an HL7 "update" sent from the HIS HL7 to the ROIS HL7 agent, which updates the information in the Archive.

2. Billing.

We assume the billing information is stored in the Archive. There needs to be some evidence (RT objects like RT treatment record, RT plan, Images) which can explain for this bill to be generated. This would pave the way for evidence based billing. The billing staff, using a billing or charge review application extracts this billing information from the Archive, reviews it for accuracy, and sends it electronically using HL7 DFT (Detail Financial Transaction) to the Hospital billing system. The Professional and Technical charges could be send to different billing systems.

3. Radiation Oncology schedule, and Treatment summary.

<This is still fairly nebulous>

A Rad Onc scheduling staff member uses a scheduling application, a component of the ROIS, to generate appointments for a patient's course of treatment. These appointments are stored in the Archive.

This triggers the ROIS, either immediately, or at the end of the working day, to send these appointments via HL7 to the HIS HL7 server.

Additions, modifications, or deletions from the Rad Onc appointments in the ROIS would similarly trigger HL7 transactions from the ROIS to the HIS HL7 server with the updated schedule information.

In addition to scheduling information, at the end of every working day (or perhaps at several times during the day) the ROIS would send a (probably simplified) treatment summary record to the HIS. The data to be included in this summary is yet to be determined.

If the patient makes appointments in other clinics in the hospital, the HIS would send the details of these appointments to the ROIS, to be incorporated into the existing Rad Onc schedule in the Archive.

It isn't clear if non-Rad Onc staff would be allowed to change existing appointments in the ROIS by this mechanism.

4. Standards & Systems

Existing HL7 transactions types for ADT and Billing

5. Discussion

This use case is similar to proposal Radiation Oncology Schedule Work Flow (ROSWF) (from IHE-JRO)

<Discussion here comparing this case with IHE-JRO use case. E.g. does Japanese HIS trigger the Rad Onc treatment course?>

DISCUSSION ON THIS PROFILE AT THE IHE RO TECHNICAL COMMITTEE MEETING ON SEPTEMBER 25, 26 2010.

New Profiles Discussion: Radiation Oncology schedule and Treatment summary (ROIS/HIS integration) 9/25 @ 11:00 [Discussion notes provided by Stuart Swerdloff]

a. Patient Demographics, Scheduling, Billing.

b. Patient Demographics between HIS and TMS, and between TMS and RO Department (Imaging, Planning, other activities). Understood.

c. Outbound Billing Information. Understood.

d. Scheduling and Treatment Summary. Need details on what information is needed for Treatment Summary (who are the users of the Treatment Summary, to what purpose will it be used). "Clinic's staff to be aware of any radiation related issue" (what level of detail is needed?, what is the role of the information, what decisions will be made based on this information).

e. All aspects of patient's medical history?

f. Is the intent that a patient who is undergoing RT ends up at the ER (for other reasons besides the primary diagnosis of Cancer?) to address the information requirements for the ER to properly diagnose and then treat the patient? What is the information about their treatment schedule that is important?

g. Integral Dose to date (to which treatment sites), Integral Dose for current course of therapy to which Treatment Site.

h. Patient Appointment schedule information (primarily appointment time for RT treatment back to the HIS so it won't double schedule the patient).

i. Intent to "archive" schedule has to do with keeping a history of what appointments were made, completed, missed, rescheduling?

j. Appointment aspects of patient having completed their RO appointmennt (time and place).

k. Medical (dose, adverse effects, inability to complete due to illness) aspects of patient having received treatment during an appointment. Who gets this information outside of the RO department? What data is likely that they will be able to read (documents? HL7 messages? DICOM Structured Report?)

l. Need a separate Use Case for Reconciliation (Patient Demographics changes on HIS, needs to go to TMS, needs to go to individual systems).

Recommendation: This use case should be compared to the existing ESI use case and draft Supplement proposal. Differences should be identified as well as any gaps.

An overview of the ESI profile is presented. PDF versions of a few slides are here

<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?>