Reporting Whitepaper - Section 6.1

<Return to the main Reporting Whitepaper page>

6.1 Hospital Department

• This is a new line in the document.

<< Note that Hospitals Departments will occasionally have to use Nighthawk services. Should probably discuss the "customer viewpoint" of Reading Service in the Reading Service Section >>

<<The Veterans Administration is usually operating as a Department (including using Reporting Services sometimes), but also wants to sometimes outsource Acquisitions. Lets cover outsourced acquisitions in the Imaging Center>>

6.1.1 Existing “State of the Art” - Northwestern Example

Radiology

Rad goes to technical operations area, gets doc of completed procedures (printed with barcodes), one sheet per “order”. It includes an ICD-9, some freetext reason, maybe some associated patient info, and handwritten notes from tech which may note use of contrast, patient motion, other sources of image problems, workflow glitches, time of exam, etc. (both PACS and RIS could capture the tech notes, but don’t communicate it well to other systems, tech is on RIS, rad is on PACS, both need the info) It’s the token for the rads reading worklist (since there’s no reporting function/worklist on the PACS or RIS).

Go to workstation, find the study, display on PACS, use dictation device, barcode in from paper to attach voiceclip to the order. Trash the paper. Dictate contents in groups Patient name, id, accession# (duplicates barcode for redundancy), procedure “name”, reason for exam (may need to create based on a variety of information, may flag as “not given” so billing will followup), technical section, discussion/findings/recommendations, conclusion, quality control (assessment of the quality of the study, not always done, patient motion, problems with technique)

QC is currently integral to the report, although it could be argued that it is part of the feedback for workflow/process improvement of order performance rather than something to record for Patient X’s medical record.

Structure of the report could be generic for 75-80% of free-text reporting. Could do fully structured templates for specific studies like Mammo screening.

Dictation is available to be called in and listened to on the phone as preliminary. Dictated status message goes to downstream systems.

Transcriptionist enters report into RIS, and sent to downstream systems as preliminary (but not hardcopy) so referring physician (limited to affiliated docs) can get fast result (and know that it has been performed and a final report is on the way). Rad is notified that it’s transcribed and does final verification. Final version goes to paper printer for mail or auto-faxing, and sent to in-patient EMR, out-patient EMR, PACS. RIS is the source of truth, rest are caching for access. Telephone and paging are used for critical results. Some sites use a phrase in dictation to flag for rapid distribution (e.g. found cancer and it’s not on the differential currently).

Report Generation Methods: Canned (Normal), Structured, “MadLibs”, Human Transcription, Speech Recognition.

Mammography

Specialty areas may have an additional system which bridges failings of general purpose systems in the same institution. Note the need for many systems/applications to contribute to the interpretation process.

Screening can be entirely structured (check off on a screen or paper) for most, and then dictate for unusual findings.

ECG

ECG takes order, acquire resting ECG, that’s tech component.

Send to data mgt system. Card uses MRN or Accession? to pull it up, type in interpretation or select canned statements from list. Digital signature applied to verify.

Alternatively, Card gets stack of pages, writes two letters on each one, transcriptionist expands the text to a report, then get reviewed by card. Report is often distributed without the traces. Traces archived in electronic system, paper traces discarded.

Distribution may be report, report with image of waveform, image without report.

Sometimes distributed as a data reference back to the ECG Mgt System.

Echo

A lot of measurements captured by tech during or right after exam. Almost universally transcribed to paper. Card does “overread” and fix the numbers as they see fit. Data is entered into the reporting system to re-associate with the report. Usually included in dictation. Often use voice templates (e.g. dictate “row 1 of the table”). Often also translate measurement in graphical representation (e.g. bullseye diagram of wall motion). Fax/email the visual presentation of the report to Referring. Inclusion into EMR systems is problematic.

Cath

Much more procedural information due to intervention aspect. A lot of non-imaging data collected simultaneously (hemo, etc.). Captured in procedure log (usually on hemo system). Draft report that is virtually complete is created at completion of procedure. Mostly text. Sent out by HL7 to EMR. Will associate/reference images of key points of the procedure. Will also include measurements (e.g. ejection fraction). These details are kept in cardiology and mostly don’t get transferred to EMR.

At the end of the month, staff go through interventional cases, screen out patients excluded for some reason, then re-code pertinent details into a structured coded submission to a registry. May also send images/report to 3rd party when doing trials on new stents, etc.

Clinical Trials

Currently captured into separate system. Formal Clinical Reports are NOT sent to trials. Some of the same information may go into another artifact which is sent to trials and additional details may be added, such as detailed measurements.

In Imaging caBIG is developing some standard annotations/markup to support their work. May be done “after the fact”.

Primary Issues

• Reporting functionality is not linked to display function. Display station does not support reporting function. Turning to another box makes the Rad mentally leave image space. Need it integrated.
• Reporting system needs to be worklist driven. Needs to be able to work from an externally managed worklist. Associated information needs to come with selection of the worklist entry. A single “application context” which may be marshalling multiple background applications and data sources. Get the CAD results, priors, report generation, EMR, etc. Want to be able to wire functions into an application interface. (Radiologist efficiency)
• Want access to all the associated evidence (images, history, etc.) from a single display and keyboard and handset. Some kind of dashboard that integrates the sources of information. Driven by a worklist, but ultimately the single screenset, keyboard, etc. can present all the available information.
• Distribution of reports is a problem.
• EMR cannot place orders robustly (it is information poor. It uses site/local dictionaries so the semantics are easily lost when other systems haven’t loaded the same dictionary. they don’t know what information is needed in an order to a department. Have a hard time including clinical details in the order), cannot “interpret” results robustly (same lack of shared semantics, use of free text in reports), cannot access images (and they are part of the meaning of the results which should be accessible). Want access to the “rich content” results produced by rad/card/mammo/etc. But need to keep the results consumable by reasonably unsophisticated/unspecialized systems. What richness gets distributed and what richness stays within the specialty dept/systems?
• Want more structure in findings. Need templates for exported results that have the right balance of including input structure by value (consumer needs to handle) or by reference (consumer has the option of retrieving). Probably work for the professional societies to develop the templates.
• Presentation of radiology results? Some feel that it is a big problem, others feel that a preferred rendering might be nice, but most renderings do not lose information or obscure meaning.
• Hard to code the report for billing at time of creation. (but is it efficient to get the rad to do it instead of the billing people) Is billing part of the report or part of the order fulfillment process? Getting the Invoice Diagnosis correct would be a big step forward. The billing system consumes reports
• Consumption of results by machines is a problem because of the lack of structure and coded data.
• Digital Signing mechanisms should be well supported and well “integrated” (e.g. don’t require re-signing on RIS when signed on special station). There are different signature mechanisms which can make it a problem to “trace/read” the signature details from other systems. Coordination is clumsy. Who is the source of truth?
• The need is that things can be signed on the system where it is most appropriate/convenient, and have that signature be accepted (not need to be repeated) by the rest of the systems. And should be able to validate/verify/confirm signatures when necessary, preferably without having to identify/locate the original signing system.
• Currently, Radiology tends to make do with Text reports until Structured reporting is figured out and available. Cardiology couldn't wait, they needed pictures so they’re moving to PDF.

6.1.2 Existing “State of the Art” – IHE-CARD

Cardiology

Lots of existing applications that are graphically focused and universally put out a PDF. DRPT addresses this. Measurements/ED can stay in that format (SR) and don't need to be transcribed into displayable reports, but need references so the receiver can go get the SR if needed.

Current Issue – having both PDF and XML in one document is not supported.

Cardiology already puts out multiple reports: to the referring physician in PDF; to JCHAO; to next interventionalist; to the administration (utilization, staff, etc), to the nursing notes/procedure log (a JCHAO req), to registries.

Cardiology leans to reports just referencing other objects. They are explicitly cautious of overloading the report and don’t feel that even a lightly coded report is worth it. The site solution will depend on where the processing is done. Maybe the department should output decision support objects separately from the report.

Feel that the data quality/details required for subsequent analysis are essentially unknown so there is little point in going beyond links in the report back to source data since you will generally have to go back to source data.

<Key assumptions:

• if you have a report, the related/referenced documents still exist and are available to you as well.
• a companion document that has been managed separately and is not the declared “document of truth” will be accepted by people/applications for automated processing

EMR Access

Three typical ways into the EMR for a physician (which are all solvable by XDS, although we need to decide if XDS is the optimal intra-hospital solution)

• Use an Enterprise EMR Terminal which is part of the EMR
• Use an Office EMR Terminal which talks to the EMR
• Use a "web portal" which talks to the EMR

6.1.3 Existing “State of the Art” – Mammography

<Need input from IHE Mammo>

6.1.5 Ring Around the Department – Proposal

One proposal is to consider the inputs and outputs of the Radiology Department from the Hospital point of view. What information goes in and what comes out?

In: Order, EMR Data

Out: Status, Prelim Report, Final Report, Coded Report, Some Images, Billing Details

RIS is inside the department and handles almost all inputs/outputs. Images may go out direct from the PACS, EMR Data may go in direct to the Reading Workstation.

<Insert Description of the diagrams in the room>