Reporting Whitepaper

This Wiki page is currently the "live" version of the whitepaper. It will later be re-integrated with the Word Document.

The optimistic goal of the whitepaper is to:

• Describe the “problem” and related details
• Break it down into component pieces
• Document some technologies that could improve things
• Propose some steps forward for coming years, including:
  • New IHE Profiles
  • IHE Profiles to be modified
  • IHE Profiles to be retired

The plan is to facilitate discussion with other IHE Domains and hopefully reach some cross-Domain consensus so we are moving in compatible directions.

Since this whitepaper is a contribution of IHE Radiology to the IHE Reporting Taskforce, the focus and viewpoint may reflect its origins. Contributions from other Domains to fill in blind-spots and balance the viewpoint are welcome.

Whitepaper Structure

Section 1 presents working premises so any disagreement about the thinking/biases underlying the whitepaper can be challenged and discussed directly.

Section 2 describes the Report itself (content).

• what information does it contain and how is it structured

Section 3 examines the Reporting Process (workflow/dataflow).

• identify the tasks surrounding reporting, the data produced and the inputs required

Section 4 describes technical issues which need to be addressed.

Section 5 presents and evaluates parts of the solution.

• for each data, identify formats for encoding;
• for each data, choose encoding most easily supported by the systems involved with that data;
  • Encodings involve semantics, so they are more domain-oriented than transport
• add as many transport mechanisms as required by the topology/variations to get all inputs and outputs where they need 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.
• select mechanisms for managing the workflow that surrounds the creation, manipulation and transportation of the data.

Section 6 introduces several real-world (Radiology) reporting environments

• describe the current typical practices (baseline expectations) and associated problems
• describe how the solution would be applied to their workflow/architecture

Section 6.1 A Radiology Department (i.e. Hospital)

Section 6.2 An Imaging Center

Section 6.3 A Reporting Service (e.g. Nighthawk, NightShift)

Section 7 proposes activities to implement/deploy the conclusions above.