Reporting Whitepaper - Section 5: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Kevino (talk | contribs)
No edit summary
Kevino (talk | contribs)
No edit summary
Line 3: Line 3:


<<Need to review table.  There are missing push/pull pairings for some artifacts.>>
<<Need to review table.  There are missing push/pull pairings for some artifacts.>>
I have a Draft Report I need to Push somewhere, so look down the 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.


{| style="width:100%" border="1" cellpadding="3"
{| style="width:100%" border="1" cellpadding="3"

Revision as of 12:19, 7 August 2007

<Return to the main Reporting Whitepaper page>


<<Need to review table. There are missing push/pull pairings for some artifacts.>>

I have a Draft Report I need to Push somewhere, so look down the 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.

Artifact Encoding Transaction Transport Dir Input/Output
Patient Summary HL7 CDA-MS ??? ??? Pull History/Allergies/Problems/Meds
Order HL7 ORM 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
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

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



Patient History Sheet

Tech Interview Sheet

Bill X12


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