Reporting Whitepaper - Section 5

<Return to the main Reporting Whitepaper page>

To populate the table:

• for each data, identify formats for encoding;
  • as few as possible; transcoding is difficult and each one adds implementation
• 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.

In a sense, the table is our catalog of transactions: I have a Draft Report I need to Push somewhere, so look down the catalog table, see that it's a type of Radiology Report which are encoded in HL7 CDA and you can push with one of two transactions depending on what transport your sender and receiver prefer.

Note that some of these artifacts that influence Reporting are created/manipulated a bit upstream from Reporting itself and in some cases their information is copied into new artifacts rather than the original artifact being passed along. E.g. rather than pass the HL7 Order to the modality, the details are copied into the Modality Worklist.

Artifact	Encoding	Transaction	Transport	Dir	Input/Output
Patient Summary	HL7 CDA-MS	???	???	Pull	History/Allergies/Problems/Meds
Order	HL7 ORM + OMI	Placer Order Management	HL7 2.3.1 Msg	Push	Order
		(Placer Order Management)	HL7 2.5 Msg	Push	Order
Worklist	DICOM MWL IOD	Modality Worklist Provided	DICOM MWM C-Find	Pull	Acquisition Worklist
	DICOM UPS IOD	(Query Worklist)	DICOM UPS C-Find	Pull	Post-Proc Worklist Reading Worklist Overread Worklist Verification Worklist
		(Push Workitem)	DICOM UPS N-Create	Push	Overread Worklist Verification Worklist
Images	DICOM Image IODs	Images Stored	DICOM C-Store	Push	Acquired Images Processed Images 3D Views
		Retrieve Images	DICOM C-Store	Pull	Acquired Images Processed Images 3D Views
Performed Proc.	DICOM MPPS IOD	Modality Procedure Performed	DICOM N-Set	Push	Acquisition
	DICOM UPS IOD	(D-Store Performed Proc)	DICOM UPS N-Get	Pull
	HL7 DFT?	(H-Store Performed Proc)	(HL7 Msg)	Push	???
Radiation Dose	DICOM SR Dose IOD	(Store Dose)	DICOM C-Store	Push	Acquisition Dose
Procedure Log	DICOM SR PLog IOD	(Store Procedure Log)	DICOM C-Store	Push
Audio	???	(Store Audio)	???	Push	Dictation
Radiology Report	HL7 CDA	(D-Store Report)	DICOM C-Store	Push	Proto Report Draft Report Overread Report Signed Report
		(H-Store Report)	HL7 2.5 MDM Msg	Push	Draft Report Signed Report
	DICOM SR?
	PDF?
Lab Results	HL7 CDA	(H-Retrieve Report)	HL7 2.5 QRY Msg	Pull
Path Results	HL7 CDA	(H-Retrieve Report)	HL7 2.5 QRY Msg	Pull
Staff Schedule	HL7 ???	Out of scope?	???	????	Staff Schedule
Staff Details	HL7 ???	<PWP>	???	Pull	Certifications

Todo

• Review the table for missing push/pull pairings for some artifacts

• May later want to add the XDS transactions for artifacts that are conveyed between enterprises.

• HL7 Pull - 2.3/2.5 Query, but there is no standard query (QRY) with a DOC message response
  • If a single result you might get the doc in the response.
  • If many results, you'd probably get URLs and use HTTP transport to pull the document you want

• Ultimately the transaction names in this table/catalogue would appear in the "scenario tables" showing how each of the section 6 scenarios "should be done".
  • Do we need bi-directional links? Should we add a "Purpose of use" column listing each scenario usage of the transaction?
  • The "Input/Output" column sort of does this now. Is it useful?

• Missing Artifacts
  • Patient History Sheet
  • Tech Interview Sheet
  • Bill X12

Proposed additions are (not entered into the table, due to complexity; but a "purpose" column should be added):

Report viewing - broadest use by patient, referrer, specialist (documents containing simple/ no specific structure):
Patient Summary, Images (web format, e.g. by WADO), Audio, Radiology Report (PDF, CDA), Results document (i.e. Lab Results, Path Results, etc. - not necessary to enumerate)

Report viewing and processing - use by specialists (dedicated objects):
Discharge Letter (i.e. superset of patient summary), images (DICOM), Radiation Dose (DICOM), Procedure Log (DICOM), Radiology Report (DICOM), Radiology Results (and other imaging specialty result objects to be further used/ processed, e.g. Pathology)

Report creation - specialist creates report using specific tools
Imaging evidence Objects or priors (DICOM), Non-imaging evidence (HL7 ORU/ OBX, CDA), Imaging report (DICOM, CDA, PDF - this depends on input and target receivers)

Reporting workflow - use by specialists (dedicated events):
Order (HL7), Worklist (DICOM), Workitem (Procedure Step - DICOM), Workitem/ Performed Procedure Step Status (DICOM)

Reporting infrastructure - helper objects to be used by report creating/ processing systems:
Vocabulary / codes (HL7/ DICOM), entities (persons, identity management - HL7)

Workflow resources or administrative objects - additional information on the organization/ processes:
Staff Schedule, Staff Details, Devices, Material

Rationale

<<In this section, consider describing the rationale for the choices for each artifact in the table. >>

Issues

CDA in Imaging

<Material from Section 3 to go in Section 5>

• Investigate CDA as an authoring and distribution format for diagnostic reports
• Two gaps are:
  • the lack of CDA report templates for a broad set of Radiology reports
  • the lack of deployed implementations using CDA

Push vs Pull

Currently most data transfer transactions are either Push or Pull, not both.

Mostly, the preference is for clients to be in control, so client inputs are Pulled (from Servers) and outputs are Pushed (to Servers). Configuration issues also favour this approach.

When bandwidth limitations cause client response times to be unacceptable to users, this is sometimes addressed by having inputs Pushed (to the client), sometimes at the cost of needing more local storage.

When explicit workflow control is "overkill", implicit workflow is sometimes implemented by having inputs Pushed (to the client). The presence of the input implies that some action should be performed on it.

When the client needs to know promptly when an (infrequently and unpredictably updated) piece of information has been updated, that input may be Pushed (to the client) to avoid excessive polling. When there is also a desire to avoid excessive broadcasts, the data push can be expanded to Publish-Subscribe.

<<Should continue to flesh out the cases where it makes sense to push inputs and pull outputs so we can add such transactions when it's appropriate and not complicate the architecture when it's not>>

<<We should start working out which nodes would prefer to pull it's inputs or have them pushed, and which would like to push it's outputs or have them pulled. It depends somewhat on the overall workflow architecture. Not sure if it goes in Section 3, Section 5, or Section 6.>>

Legacy Migration Considerations

The current installed base uses a wide variety of report formats and transfer mechanisms. This variety exists by purpose or for historical reasons. IHE should consider what options can reasonably be provided to allow users:

1. to make little changes (small-step migration)
2. to radically switch to one single technology.

A first examination of this was done with the Springfield-Futurama exercise earlier in this project, and should be repeated using the new "tools" developed here. IHE should describe such transformation and migration scenarios. Conflicting pressures include Implementation Convergence vs Supporting as Many Legacy Variations as Possible. The solution will likely involve ways to upgrade different sections of the chain separately.

The DICOM Strategic Committee also considered this topic. Its Reporting Strategy Paper and describes some thoughts on when to use DICOM SR and HL7 CDA.