Backing Standards and Profiles for the RO-HIS / ROWE Profiles

• The Problem
  • Currently, multiple health information systems used for each purpose – and patient information not shared
  • Manual copying of data from one system into another is error prone / time consuming
  • Changes made in one system do not update in other (name change/contact info)
• The Solution
  • Bidirectional flow of patient demographics and scheduling from hospital information system (HIS) and Treatment Planning System (TPS) and Treatment Delivery System (TDS)
• The Benefit
  • Improved accuracy of data
    • Charge Capture more timely / accurate
    • Patient contact info more accurate
  • Clinical staff performance improvement
    • Increased efficiency: Only need to perform function once
    • Fewer distractions of having to reconcile multiple systems
• Issues for Discussion
  • WHAT demographics need to transfer?
    • Name, MRN, DOB, Ins, contact info, diagnosis, charges, scheduling
  • Important to have appointment flexibility and control over linac schedule
    • Directionality of scheduling – which system overrides other?

The IHE Product Registry can be useful for seeing product support for profiles and transactions.

The existing CPRO Clinical Impact Statement states

This profile will use the same transactions used in the IHE Radiology Scheduled workflow profile.

Scheduled Workflow and its extension Patient Information Reconciliation has two relevant transactions, “Patient Registration [RAD-1]” and “Patient Update [RAD-12]”, corresponding to transaction ITI-30. It is based on transactions from ITI Patient Administration Management.

Additionally, the profile Patient Demographics Query - PDQ defines a way of searching for a patient.

Are all mentioned field included in the use case? Are any additional RO-specific fields needed?

In Scheduled Workflow, the two relevant transactions are Procedure Scheduled [RAD-4] and Procedure Updated [RAD-13]. It seems very much one-directional with one master scheduling system and no means for querying a patient's schedule.

The ITI profile Patient Administration Management (PAM) concerns only the current or historical locations of the patient, not scheduling.

Epic have documented Incoming and Outgoing Scheduling interfaces as well as schedule queries with seemingly large integration base (Mosaiq, ARIA, Cerner, IMPAX, etc.). Could this be inspiration for a bi-directional scheduling interface? Are there other profiles that already support this? Based on HL7 v2.x. The querying specification is not immediately available - contact Epic for getting the spec.

The use case needs more detail on the scheduling of different kinds of appointments, e.g. treatment sessions.

Chapter 10 of the HL7 standard version 2.5.1 and 2.7 (at least) is a very well-written description of the HL7 scheduling model. The transactions are divided into “request transactions”, “query transactions” and “unsolicited transactions”, corresponding to booking requests (that can be denied), booking queries (for finding appointments and blocked timeslots) and notifications of booked appointments.

This was not explicitly mentioned in the PC use cases, but has been previously discussed in TC and exists in a rudimentary form in Epic today.

• IHE XDS (Cross-Enterprise Document Sharing) requires document repository.
• IHE XDR (Cross-Enterprise Document Reliable Messaging) pushes data
• IHE RID (Retrieve Information for Display) is read-only display of primarily unstructured data, e.g. CDA level 1, PDF
• IHE MHD (Mobile access to Health Documents) is a REST-based service
• HL7 FHIR MHD is scheduled to be updated to use this when FHIR is released in a final text version.

XDS still appears to be the primary contender for now. Flow to submit a document looks like this:

Document Source->Document Recipient: Provide Document Resources [ITI-65]

To query and retrieve the archive, there are more transactions:

Document Consumer->Document Document Responder: Find Document Manifests [ITI-66]
Document Consumer->Document Document Responder: Find Document References [ITI-67]
Document Consumer->Document Document Responder: Retrieve Document [ITI-68]

Formats alternatives:

• Display
  • CDA level 1
  • PDF
  • HTML
• Structured
  • CDA level 3 / CCD
  • DICOM-SR
  • FHIR

XDS-MS (Medical Summaries) and XDS-LAB uses CDA level 3. Could FHIR be a contender? DICOM-SR? PDF?

The content module in XDS-MS is very medicine-centric and looks hard to reuse.

The work on the Ambulatory Oncology EHR Functional Profile seems paused - see also http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=609 .

Could the Implementation Guide for Ambulatory Healthcare Reporting to Cancer Registries be instructive? The content definitions there seems much too vague, but perhaps it could be included as a lower level of reporting.

As an actual content template for inspiration we can probably use the ASTRO Radiation Oncology Survivorship Care Plan Template, or is there a different scope for this profile?

Quoting that template:

The aim of this ASTRO-sponsored Survivorship Care Plan (SCP) template is to formulate a standardized treatment summary and survivorship care plan template that can be used across radiation oncology.

There is a IHE Radiology profile Charge Posting - CHG that seems useful. with the transactions “Charge Posting - RAD-35” and “Account Management - RAD-36”. There are no corresponding ITI profiles or actors.

DSS/Order filler->Charge Processor: Charge Posted (DFT^P03)

The “Account Management” transaction concerns opening, closing and updating the patient account, containing diagnosis codes, guarantor information and insurance information.

Should the actual event codes sent be included in the profile, or is that configuration?