Reporting Whitepaper - Section 3

<Return to the main Reporting Whitepaper page>

The Reporting Process

Identify the "process nodes" that make up and surround reporting.

• what controls/triggers/constrains/cancels the activity
• what input data is required (particularly data which is transformed/transfered into the output)
• what ouput data is produced (both the product of the activity and the status/meta-output)
• what activities define/occur at the node
• what exceptions/variations exist

Questions and Issues

<<How do we want to reflect the exception case where imaging is done but no radiologist report is ever created. For example simple fractures may be interpreted by an attending physician. Since a radiology report is not created, the official record of the finding is ...?>>

<<Rita will document what the architecture looks like when you have hospitals that don't have any radiologist infrastructure; that it is completely outsourced to another group which provides radiologists and radiology IT to multiple sites.>>

<<Are there additional nodes in, for example, Cath workflow, to represent a report "drafted" during the procedure. Is there a second half to the drafting step? or is the first part a pre-drafting step?

<<Our primary model here is reporting for diagnosis. How to reflect the differences between reporting for Intervention/Treatment vs Reporting for diagnosis>><<Stick to diagnosis and build in treatment based on a general treatment model>>

<<Do we need to look into the "summary" report/flavors of reports for different consumers. This was rejected in the past>>

<<Consider notation to show which inputs/outputs/controls are critical vs which are supplemental>>

<<Should we differentiate between nodes that add information vs ones that just transcode it vs ones that just move it?>>

<<Insert Diagram of nodes and the data flow>>

<<In different architectures, different nodes are located/connected differently>>

<<Need to map inpatient/outpatient, Dept vs Clinic vs …, Intra-Enterprise vs Inter-Enterprise>>

<<This exercise has not yet, but probably should, try to benefit from current workflow tools. BPMN, XPDL and BPEL are described and related here: [1]

• BPMN (Business Process Modeling Notation) is a standardized graphical notation for drawing business processes in a workflow. BPMN’s primary goal is to be readily understandable by all business stakeholders and thus serve as common language to bridge the communication gap that frequently occurs between business process design and subsequent implementation.
• XPDL is effectively the file format or "serialization" of BPMN. It offers a one-for-one representation of the original BPMN process diagram. Its primary goal is to store and exchange the process diagrams, or specifically to allow one tool to model a process diagram, and another to read the diagram and edit, another to "run" the process model on an XPDL-compliant BPM engine, and so on.
• BPEL is an "execution language" the goal of which is to provide a definition of web service orchestration, the underlying sequence of interactions and the flow of data from point to point. You can take a BPMN diagram and produce BPEL, but it is difficult or impossible to recover the original BPMN diagram from the BPEL. This is not surprising since BPEL was not designed for process design interchange.

{P1} is used to show specific instances of data for reference later to match specific inputs to specific outputs.

Consider if we want to use them to make "equations", e.g. D4 = W1 + D1 + D2

Keep in mind the needs of each of the large process(es) to which reporting contributes:

• Clinical
• Research
• Education
• Administration (operational)
• Management (planning)

Order Phase

Order Phase activities lead up to the Reporting work. The early steps have less to do with reporting and are only sketched in for context/reference and to show the source of information used later.

Registration

{Pay no attention to this man behind the curtain. Out of scope, just here for context}

In:

• [Existing Account] {P1}

Out:

• Patient Account {P1} (new or updated)

Activity: Create/Update the patient demographics

Exceptions: May be backfilled afterwards in case of emergency.

• "Visit" is really an account of a different flavor

Ordering

In:

• Patient Account {P1}

Out:

• Order {O1}
  • Order Placed Date/Time
  • Reason for Study
  • Admitting Diagnosis (ICD-9)
  • Ordering Physician
  • Type of Study
  • Order Priority

Activity: Place an order for Radiology services, providing clinical context/need.

Exceptions:

• May be backfilled afterwards in case of emergency.
• Current state: many times a paper requisition is an output of the ordering process. The req will often contain patient demographic info, procedure info, and a token for the order (e.g. accession). The req is then used to drive processes like acquisition and reading.

Scheduling

In:

• Order {O1}

Out:

• Acquisition Worklist {W1}

Activity: Put item on acquisition worklist, possibly specifying timeslot and/or equipment

Exceptions: Appointment may be set before the order is created.

Data Acquisition

Control:

• [Acquisition Worklist {W1}]
• [Unscheduled case]
• [Patient Consent]

In:

• [Acquisition Worklist {W1}]
• [Manually entered order & demographics]

Out:

• Acquired Images {D3}
• [Acquired ECG {D10}]
• [Acquired Hemodynamics {D11}]
• Performed Procedure Details {S1}
  • Acq. Start/Stop Date/Time
  • Description of Performed Procedure
  • Contrast administered/lot number
  • Checklist completion (check consent, check pregnancy, etc.)
  • Billable Materials Usage
  • Billable Tasks Performed
  • Tech Comments
• Radiation Dose {D5}
• Procedure Log {D6}
• Status update (e.g. complete or acquired)

Activity: Perform the requested scan, etc.

Exceptions:

• Unscheduled acquisitions. Handling repeats. Aborted procedures. Additional Consents?
• For Cath, draft report that is virtually complete is created at completion of procedure. While this is mostly text, at some point they associate/reference images of key points of procedure. <Need more input from cardio...>
• For Imaging Centers with lack of connectivity to ordering institutions, may replicate a local "registration/ scheduling" or may do manual entry like unscheduled

Data Processing

Control:

• [Processing Worklist] {W2}
• [Input Availability] {F1}

In:

• Acquired Data {D3}

Out:

• Processed Images {D7}
• 3D Views {D12}
• Measurements {D18}
• CAD Results {D13}
• Clinical Analysis {D14}

Activity: Perform requested 3D Reconstructions, CAD, etc.

Who judges and applies Input Availability?

• Client internal logic based on reading item on the worklist (with inputs listed) and recieving notification broadcasts directly. This has the advantage of the client being able to make it's own "subtle" decisions.
• Worklist Manager logic that recieves notifications and either keeps the item off the worklist until inputs are available, or flags the item as to whether inputs are available. This has the advantage of centralizing the workload (fewer systems have to be smart, fewer messages have to be broadcast)

Creation Phase

Creation Phase activities involve generation of the report.

Reporting Workflow Management

Control:

In:

• Order (aka Reading Request) {O1}
  • Order Placed Date/Time
  • Admitting Diagnosis (ICD-9)
  • Type of Study
  • Order Priority
• (Should these two come from the images since the acquisition might not follow the order?)
  • Modality of Study
  • Anatomy Imaged

• Staff Schedule {H1}
• Staff "Certifications" (What/Where they can read) {H2}

Out:

• Reading Worklist {W4}

Activity: Coordinate/distribute the work for reporting.

For Reading Service this would be an internal activity, with external inputs.

<Should we reflect all the individual activity completions as outputs that come back to the workflow management node so people can see status/progress in detail? Is there any reason to broadcast those?>

Exceptions:

• Current state: this is often managed via a printed or scanned list of completed procedures that are manually "handed out" or "pulled" based on availability.

Data Marshalling - Initial

In:

• Acquired Images {D3}
• Processed Images {D7}
• 3D Views {D12}
• Measurements {D18}
• CAD Results {D13}
• Clinical Analysis {D14}
• Prior Images {D8}
• Prior Reports {D9}
• Order {O1}
  • Reason for Study
  • Admitting Diagnosis (ICD-9)
• Other Orders (Recent & Prior) {O1?}
• History/Allergies/Problems/Medications {P2}
• Lab Results (Current, Prior)
• Pathology Results (Current, Prior)
• Patient History Sheet
• Tech Interview Sheet
• Tech comments (e.g. note regarding contrast usage, patient movement, time of exam, image issues, etc.)
• Contact Information (for performer of acquisition, physician(s) responsible for patient)

Out:

• Flag - Study "Ready to Read" {F3}
  • [Time/Date of Availability]
• Count of Images to Read (for legal reasons)
• Completeness of Data (what is missing, how many priors are there, etc)

Activity: Collect the necessary inputs for the Reading node and decide "readiness".

Exceptions:

• "Wet Reads" do minimal marshalling (just the current data).
• For Reading Service the order and other data may be coming from another organization

Review/Reading

Control:

• Reading Worklist {W4} <Workflow management (Overdue? Exception Mgt?)? Worklist partitioning?>
• [Flag - Study "Ready to Read" {F3}]

In:

• "Marshalled Data"

Out:

• Accession #

Activity: Select, view and manipulate as necessary the images and other data.

Consultation - Reference Materials

In: <<Depending on the sophistication, the reference system might use some case details>>

• Order {O1}
  • Reason for Study
  • Admitting Diagnosis (ICD-9)
• Patient Demographics
  • Age
  • Sex

Out: <<Probably none? Report text?>>

Activity: Access/Review reference information relevant to the study (e.g. Teaching Files, "StatDX", etc.)

Exceptions: <<Would Decision Support be a form of this?>>

Consultation - Peer/Expert

In:

Out:

Activity: Review/Discuss the case with another professional. The peer will need access to relevant images and data. The Reading Radiologist and Peer will need to confer/collaborate.

Exceptions: <<Should we make the Face-to-face consultation an exception and remote consultation the norm?>>

Interpretation/Dictation

Control:

• Accession #

In:

• Reading Worklist <Provides relationship/context information>
• [Report Templates/Standard Text Blocks]

Out:

• Findings/Conclusions as Voice Audio? {R1}
• [Proto Report] {R2}
• [References to Images?] {R3}
• [Report Start/Stop Date/Time] {S4}
• Flag - Delay for ...
• Flag - Requires Followup (e.g. Mammo - get specific flags)
• Flag - Critical Results
• Flag - Image QC Issue/Comments
• Flag - for Teaching File
• Flag - for Clinical Trial Candidacy
• Flag - for billing follow-up
• Status update (e.g. dictated)

Activity: Interpret the images/data and dictate/record those findings.

The radiologist may set several “delay flags” (see IHE Teaching Files and Clinical Trials) indicating that the interpretation activities are complete, but the report should be considered incomplete until the associated lab/pathology/etc data has been marshaled for inclusion.

A "Proto Report" is a technical construct and should not be considered a draft report since it is more machine readable than human readible. It would contain things like coded references to source data and/or images, fragments of text, coded measurements, coded findings, etc. Together with the dictation, the proto report can be used to create a draft report with coded content.

In common cases the reading may be performed in parallel by two different resources (blind overread, QC, resident/attending)

Exceptions:

• Multiple reports based on audience: Cardio might put out multiple types of reports based on audience (e.g. referring, next interventionalist). In the future many reports might have a clinical version with all the rich detail and a patient consumable version with layman's terms and a recommendation.
• Should we come back to template based/checklists/selection/typed entry reports? <Some places may use them for normals but devolve to dictation if something seen>
  • Ability for Rad to create and sign in one step via canned/normal templates, structured reports, "MadLibs"
• In the case of ECG sometimes card gets stack of pages, writes 2 letters on each, transcriptionist expands text to report.
• In the case of Echo, card reads and fixes numbers as they see fit and then enters into report (usually via dictation)
• Card often translates measurements into graphical representation at this point (e.g. bullseye diagram of wall motion)
• Reading Service could have different Templates for each customer site or referring physician.

Dictation/Transcription

Can we make this a single node with two locations interacting with one system since this seems to reflect current and desired practice better?

Think about how we would model

• traditional dictation/transcriptionist (separated in time and space)
• full voice recognition (where the transcription is completed immediately)
• correctionist (where the transcriptionist "spell checks" the voice rec)
• non-voice report creation (e.g. using templates, madlibs, etc.)

Transcription/Authoring

Control:

• Transcription Worklist {W5}

In:

• Voice Audio {R1}
• Text from prelim report (e.g. correctionist workflow) {R2?}
• [Proto Report] {R2}
• [References to Images, source documents (e.g. cardio measurement), multimedia (e.g. AVI)?] {R3}

Out:

• Draft Report {R4}
• Status update
• Draft Availability Notification to rad
• Verification Worklist item {W6}

Activity: This step will have several different flavors.

• Traditionally it is performed by a transcription service located somewhere else with a human listening to the audio and entering simple electronic report text. The text may be a single “block” or may be separated into several sections with titles.
• Some transcription services are using voice-recognition systems and a human “correctionist”.
• A few sites put the voice-recognition on the “dictation” system itself in an attempt to compress most of the activities from Review to Signature into a single step.

<Add something about feedback, e.g. a note to the Rad from the Transcriptionist, phone calls, IM, etc.>

Data Marshalling – Final

Control:

• Flag - Delay For...
• Input Availability

In:

• Draft Report
• Referenced Additional Data (see Delay Flags)

Out:

• Draft Report (Updated with delayed data)

Activity:

<Are there other kinds of “follow-up flags?”>

Over-read

Control:

• Reading Worklist <Workflow management (Overdue? Exception Mgt?)? Worklist partitioning?>

In:

• "Marshalled Data"
• Draft Report
• [Report Templates/Standard Text Blocks]

Out:

• Overread Report

Activity: Read a study that has already been read by another radiologist. Done for the purpose of avoiding errors, performing QC, and/or when the overreading physician is legally responsible for the patient.

Exceptions:

• For Reading Service reports, Overread by the requesting organization is often mandatory. The overread may also require changing the report format to local standard. Due to lack of connectivity, often the over-read is entered as the "real" draft report and the rest of the workflow is as described. State requirements cause (currently difficult to manage) variability in details/formats required.
• If we have a large hospital providing Reading Service for smaller hospitals this might an ongoing outsourcing arrangement in which case the reading service would do it's own overread and be more integrated systems.
• Some overreads may be "blind" (the overreading physician does not have access to the original readers draft report until after they have completed their own report).

Differential Reconciliation

In:

• Draft Report
• Overread Report

Out:

• Discrepancies Report (for the case)
  • (Often statistically compiled over time (and subdivided in various ways, by doc, by site, etc.) and used for QA, both internally and in the case of Reading Service distributed back to them. Often used to "rate" radiologist accuracy and productivity)
• Flag - Significant Difference
• Reconciled report
• Status update?

Activity: The overreading radiologist flags differences (discrepancies) between their report and the draft. Usually this will be done together with the Overread task itself.

Exceptions:

• For an Attending/Resident overrread, usually the senior is "right".
• For Reading Services, usually there is a consultation between the two rads. Sometimes the differences are the result of having less information available compared to the requesting institution radiologist.
• For QA, there is likely a consulation as well.
• Sometimes a reading service radiologist will be more "senior" than the requesting institution

• In the case of a blind overread, who identifies differences? 3rd Radiologist? The 2nd Radiologist after completing their own report?

<Do we need a node for review of the discrepancies report by the original reader (e.g. as a learning step)? Or is that simply a normal "distribution" node>

Verification/Finalization

Control:

• Verification Worklist {W6}

In:

• Draft Report
• Full set of marshalled data or just the images?
• [Voice Audio] <remove?>

Out:

• Signed Report or Final Report (Signed)
• Flag - Significant Difference
• Status update
• Distribution trigger/notification?

Activity: The radiologist scans the report to see if it looks internally consistent and matches their memory. They may check the images to refresh their memory.

<<How are corrections handled? Do they correct it directly or is it sent back to transcription with a dictated note about what to change/fix?>

They will generally not listen to the audio because the point is to be satisfied that the text reflects the case/patient, not that the text reflects the audio.

Exceptions:

• Verify always involves a signature (if you won't sign it, why do we trust you to verify), but signature does not always result in finalization. <Clarify>

Distribution Phase

Distribution Phase activities involve getting the report to the consumers. Note that this grouping means a couple steps are listed out of sequence. Preliminary Access (a Distribution Phase step) could happen right after initial Transcription/Authoring (a Creation Phase step) was complete.

<Consider if the variety of distribution mechanisms should be in Section 3, e.g. fax, email, hardcopy (sneakernet, snailmail, courier), electronic messaging, web, etc.>

<Note that consumers will be more broad that referring physician and will often include other EHRs, RHIOs, PACS, etc.>

<Note that for ECG the distribution can be just report, report with image of wave form, image without report, or data references back to source ECG Mgmt System>

Preliminary Access

Out: Draft Report

<<Also add the voice audio of the dictation available over the phone. Usually used when time/location restrict your access to the text report. Not a primary method but a useful backup.>>

Activity: Making the draft report available to interested parties (usually those treating the patient).

May be distributed to multiple destinations.

Preliminary distribution is particularly important for Reading Services since it's the reason for doing it. If they could wait for the local final report, there's no need for the reading service.

Exceptions:

Critical Results Notification

Control:

• Critical Results Flags
• Significant Difference Flag

In:

• Order (Referring)
• PWP Contact Info
• On-call/work schedule
• Prelim Report or Signed Report

Out:

• Signed Report
• Notification

Activity: Notify referring or other relevant physician that the report contains urgent/critical findings.

Exceptions: Note there are levels of urgency which dictate different notification strategies.

• If there is not way to distribute Draft/Preliminary Reports (or if they have not been distributed) the Significant Differences might not trigger notifications.

Receipt of Report? of Notification?

In:

• Signed Report
• Critical Results Flag
• Significant Difference Flag

Out: Confirmation?

Activity: <Audit trails might be a reciept for an electronically accessed report. Note the difference between record of a Pull By Recipient, vs Push To Recipients Expected Location.> <High levels of Urgency might dictate "stronger" reciept confirmation than lower levels> <Some cases ought to invoke a "consultation"> <In the case of a Fax/hardcopy it's much harder> <Some systems require the recipient to call in to a site and "read back" the result to the receipt confirmation system>

<Should we be thinking about receipt of the notification (in which case this node might be part of the previous node), or receipt of the report?>

Typical Result Notification

In:

• [Draft Report Available]
• Final Report Available

Out:

• [Reference to Report for access from ERR/HIS/EMR]

Activity: Normal notification of availability of an ordered report.

"Internal" Distribution

In:

• Signed Report
• recipients w distribution method for each recipient (e.g. fax, email with link, page, etc.)

Out:

• Signed Report
• Audit Trail

Activity: Making the Signed report available to interested intra-enterprise parties (usually those treating the patient, but could also included interfaced systems such as EHR, PACS, RIS). Some referrings have access to internal systems as "affiliated docs".

"External" Distribution

In:

• Signed Report
• recipients w distribution method for each recipient (e.g. fax, email with link, page, etc.)

Out:

• Signed Report
• Audit Trail

Activity: Making the Signed report available to interested inter-enterprise parties (usually those treating the patient). This would include distribution to referring, outpatient EMR, PHRs, RHIO?, etc.

Consumption Phase

Consumption Phase activities involve using the contents of the report or output of the reporting process.

Order Closure

Control:

• Final Report[s] Notification

Out:

Activity: Feedback to Order Placer that it has been filled.

Note that this step might actually happen immediately after signature/finalization and the notification steps happen in parallel.

Complexity when there are multiple parts to the order and tracking when the total is complete.

Procedure Coding/Findings Coding

In:

• Order
• Performed Procedure Details
• Signed Report
• Procedure Codes (what's been assigned so far)

Out:

• Procedure Codes

Activity: Ideally this would happen during performance of the procedure and authoring of the findings. Typically it happens separately later for a number of reasons.

Even rule-based coding will involve constant maintenance as new billing codes appear and payor policies and hospital policies change and department procedures change.

Natural Language Processing (NLP) can help transform inputs to outputs.

Decision Support

In:

• Findings (pathologies)

Out:

Outcomes Analysis/Quality Measures

In:

• Findings (pathologies)
• [Cancer Staging Information]
• [Left Ventricular Function]

Out:

• [Registry Submission]

Activity: Compiling information correlating particular disease findings and subsequent outcomes, correlating pathologies found and modality/study used, effectiveness of the interventions/therapies applied and outcomes, etc.

Ideally this would happen during performance of the procedure and authoring of the findings. Although it typically happens separately later for a number of reasons, in some cases this is more tractable than general procedure/finding coding because these are often smaller scope focussed projects with a limited number of things to code.

Natural Language Processing (NLP) can help transform inputs to outputs, particularly for things beyond coding the basic procedure and findings. Research can get into many areas. Have to deal with "regularization" of terminologies.

Might be done both locally to the hospital or nationally via a registry or shared between research groups, etc.

<Would Clinical Trials workflow be handled here or elsewhere in the process?>

Billing

Control:

In:

• Order
• Performed Procedure Details
• Procedure Codes
• Patients Insurance Details
• Final Report[s]
• Final Report Notification[s]
• Pre-certification

Out:

• Bill
• Claim Attachments (indications, procedures preformed)

Activity:

<Note output could go directly to the payor, to a clearing house, or to a local billing partner>

<do we need to add nodes where one provider bills another? e.g. >

Archival Phase

Archival Phase activities involve storing the data and making it available later as needed. Part of the difference between the Distribution Phase and the Archival Phase is the difference between "current data" and "historical data".

Archiving – Operation & Legal

In:

• Signed Report

Out:

Who will archive copies of the report (for what scope/timeframe/purpose)?

• Report for a Minor has to be held for X years, for an adult, 7 years
• Liability limitations
• Even with spinning disk archiving Disaster recovery

Who is the authoritative source of the report?

How do you deal with multiple copies? What if they're different? (e.g. addendums)

Recording the test and findings in the patients EHR, incorporating the report into the medical record. Consumption or Archival?

Do we document the various cases here? E.g. Reporting Service keeps studies online for a week for distribution availability, but archiving is considered the responsibility of the requesting institution.

Accessing Priors

Who retrieves archived reports and where do they want to get them from?

<Should we also discuss transfer of medical records here? Patient moves to Phoenix>

Next Step

Now all we have to do is connect the nodes according to the inputs/outputs, assign transaction numbers, choose a preferred encoding (and one or two transports) for each transaction, and consolidate any identical transactions.