Reporting Whitepaper - Section 3

<Return to the main Reporting Whitepaper page>

The Reporting Process

Identify the "process nodes" that surround reporting.

• what input data is required
• what controls/constrains/triggers the activity
• what data is produced
• what is the nature of the activity
• what exceptions/variations exist

<<Do we want to indicate if the node system would prefer to pull it's inputs or have them pushed, or if the node system would like to push it's outputs or have them pulled, or is that getting into design work for a later section?>>

<<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, 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.

{D1} 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.

Registration

In:

• [Existing Account]

Out:

• Patient Account {D1} (new or updated)

Activity: Create/Update the patient demographics

Exceptions: May be backfilled afterwards in case of emergency.

Ordering

In:

• Patient Account {D1}

Out:

• Order {D2}
  • Order Placed Date/Time
  • Reason for Study
  • Admitting Diagnosis
  • 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 {D2}

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]

In:

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

Out:

• Acquired Data {D3}
  • Images/Radiology Data <note that this could also be cardio data for ECG and Echo (e.g. resting ECG) as well as non-imaging data (e.g. hemo) for Cath>
• Performed Procedure Details {D4}
  • 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...>

Imaging Centers may end up with manual entry like unscheduled due to lack of connectivity with requesting institutions, or may replicate a local "registration/scheduling"

Data Processing

Control:

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

In:

• Acquired Data {D3}

Out:

• Processed Data {D7} <split up later>

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

Creation Phase

Creation Phase activities involve generation of the report.

Reporting Workflow Management

Control:

In:

• Reading Requests/Orders
• Modality of Study
• Type of Study
• Anatomy Imaged
• Order Priority (e.g. STAT)
• [Time/Date of Request]
• Staff Schedule
• Staff "Certifications" (What/Where they can read)

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:

• Radiology Data (Current, Additional, Analysis/Measurements, Priors, Prior Reports)
• Order (Reason for Study) {D2}
• ICD-9 code (diag)
• Other Orders (Recent & Prior)
• History/Allergies/Problems/Medications
• Lab Data (Current, Prior)
• Pathology Data (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:

• "Ready to Read" Notification {W3}
• [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

Interpretation/Dictation

<figure how to show this as two steps (to see what we learn) because of box separation, but reflect that to the user it is really one task>

Control:

• Reading Worklist {W4} <Workflow management (Overdue? Exception Mgt?)? Worklist partitioning?>
• ["Ready to Read" Notification {W3}]

In:

• "Marshalled Data"
• Reference materials (Teaching Files, "StatDX", etc.)
• [Report Templates/Standard Text Blocks]

Out:

• Findings/Conclusions as Voice Audio?
• [Proto Report]
• [References to Images?]
• [Report Start/Stop Date/Time]
• Delay Flags
• Followup Flags (e.g. Mammo)
• Critical Results Flags
• Image QC Comments
• Flag for Teaching File
• Flag for Clinical Trial Candidacy

Activity: 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.

<<Provide explanation of Proto Report>>

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

Exceptions: 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>

Reading Service could have different Templates for each customer site or referring physician.

Transcription/Authoring

Control:

• Transcription Worklist

In:

• Voice Audio
• [Proto Report]
• [References to Images?]

Out:

• Draft Report

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:

• Delay Flags
• 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

In:

Out:

Activity

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.

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)
• Significant Difference Flag

Activity: The overreading radiologist flags differences (discrepancies) between their report and the preliminary. For an Attending/Resident overrread, usually the senior is "right". For Reading Services, usually there is a consulation between the two rads. 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? Or is that just a normal "distribution">

Exceptions:

For Reading Services, sometimes the differences are the result of having less information available compared to the requesting institution radiologist.

Verification/Correction/Confirmation

Control:

• Verification/Over-read Worklist

In:

• Draft Report
• [Voice Audio]

Out:

• Final Report
• Significant Difference Flag

Activity: (Two kinds of verify, 1 to verify transcription, 1 to overread). In both cases they want access to the images.

Exceptions: wouldn't listen to the audio.

Signature/Finalization

Control:

• Signature Worklist

In:

• Final Report

Out:

• Signed Report

Activity: <Consider reworking this and the above to be one node which is "Verify with intent to Sign" and another with is "Verify for some other purpose" e.g. QC overread, etc.>

Really 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.

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 could happen after initial Transcription/Authoring 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.>

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:

Urgent/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 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). 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, 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, partiicularly 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.

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

Archiving Phase

Archival – 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.

Prior Access

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.