Reporting Whitepaper - Section 3

<Return to the main Reporting Whitepaper page>

The Reporting Process

This section should at least cover the first two of the following steps:

• First, identify all the tasks surrounding reporting
• Second, identify the data produced by each task and the input data required
• Third, identify encodings for each data that are sufficiently expressive
• Fourth, choose encoding most easily supported by all the systems involved
  • Encodings involve semantics, so they are more domain-oriented than transport
• Fifth, add transport mechanisms as required by the topology to get each input and output where it needs to go
  • Where possible, use generic transport. There’s a reason DICOM dropped the 50-pin plug.
  • Corollary: But validate that the generics work for our use cases in the real world.

Keep in mind the processes which provide context(s) for reporting: Clinical, Research, Education, Administration (operational), Management (planning)

Process Nodes

The following are the nodes/activities in the Reporting Process.

The sequence roughly follows the phases of the reporting process: (for the sake of argument) Creation, Processing, Archiving, Distribution and Consumption.

(Try to stick to Radiology and Reporting for now.)

<<Insert Diagram of nodes and the data that comes into/out of each>>

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

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

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

For each node, consider:

• the input data (i.e. the external artifacts that it depends on),
• the output data (i.e. the artifacts that are generated and generally distributed), and
• the activity (i.e. the details of what is performed in the node)
• (add triggers?)

Note that the current inputs are bare-bones precursors to the outputs. As we add more details to the activities, there will be additional inputs that the node would be interested in, but are not strictly necessary for any given output.

Registration

In:

Out: Patient Account

Ordering

In: Patient Account

Out: Order

Scheduling

In: Order

Out: Worklist(item)

Activity: (Clarify as specifically assigning a time slot or just putting it on the Dept Worklist)

Exceptions: the appointment may be set before the order is made.

Data Acquisition

In: Worklist

Out: Acquired Data (Images/Radiology Data); Performed Procedure Details (Radiation Dose, Contrast administered/lot number, Description of Performed Procedure, Procedure Log, Tech Comments, Checklist completion (check consent, check pregnancy, etc.), Billable Materials Usage, Billable Tasks Performed)

Activity: Perform the requested scan, etc.

Exceptions: Handling repeats? Aborted procedures? Additional Consents?

Data Processing

In: Current Radiology Data, [Worklist]

Out: Additional Radiology Data

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

Data Marshalling - Initial

In: Radiology Data (Current, Additional, Analysis/Measurements, Priors, Prior Reports), Order (Reason for Study), Other Orders (Recent & Prior), History/Allergies/Problems/Medications, Lab Data (Current, Prior), Pathology Data (Current, Prior), Patient History Sheet, Tech Interview Sheet

Out: Notification of Readiness

Activity: Collecting together the necessary inputs for the Reading node and deciding "readiness".

Review/Reading/Interpretation/Dictation

In: Worklist, Marshalled Data, [Notification of Readiness]

Out: Voice Audio, [Proto Report], [References to Images?] Delay Flags, Followup Flags (e.g. Mammo), Critical Results Flags

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.

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

Transcription/Authoring

In: Worklist, Voice Audio, [Proto Report], [References to Images?]

Out: Draft Report

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.

Preliminary Access

Out: Draft Report

Exceptions: Is this where we handle "recalled" reports, when there is an overread exception?

Data Marshalling – Final

In: Delay Flags, Draft Report, Referenced Additional Data (see Delay Flags)

Out: Draft Report (Updated with delayed data)

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

Verification/Correction/Confirmation/Over-read

In: Draft Report, Voice Audio?

Out: Final Report

Signature/Finalization

Out: Signed Report

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

Urgent Notification

In: Order (Referring), PWP Contact Info

Out: Signed Report

Receipt

In: Signed Report

Out: Confirmation?

Typical Notification

Should Order Placer get a reference to the report in the status msg so to help the ordering physician who checks status be able to retrieve the report from the Enterprise Report Repository (HIS, EMR, etc) more easily? And do we differentiate between the Report Completion defining the end point, or do we need to receive completion of each of the composite steps? Release

Order Closure

Feedback to Order Placer that it has been filled.

Procedure Coding/Findings Coding

In: Order, Performed Procedure Details

Out: Procedure Codes

Activity:

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.

Billing

In: Order, Performed Procedure Details, Procedure Codes Out: Bill Activity:

Archival – Operation & Legal

In: Current Report

Out: Prior Reports

Recording the test and findings in the patients EHR, incorporating the report into the medical record.

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

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