Difference between revisions of "Reporting Whitepaper - Section 5"
Line 16: | Line 16: | ||
| DICOM MWL IOD || Modality Worklist Provided || DICOM MWM C-Find || {W1-Pull} || | | DICOM MWL IOD || Modality Worklist Provided || DICOM MWM C-Find || {W1-Pull} || | ||
|- | |- | ||
− | |rowspan="2"| DICOM UPS IOD || ''(Query Worklist)'' || DICOM UPS C-Find || {W2-Pull} | + | |rowspan="2"| DICOM UPS IOD || ''(Query Worklist)'' || DICOM UPS C-Find || {W2-Pull} {W4-Pull}<br>{W5-Pull} {W6-Pull} || |
|- | |- | ||
− | | ''(Push Workitem)'' || DICOM UPS N-Create|| {W2-Push} | + | | ''(Push Workitem)'' || DICOM UPS N-Create|| {W2-Push} {W5-Push}<br>{W6-Push} || |
|- | |- | ||
|rowspan="2"|Images | |rowspan="2"|Images | ||
Line 30: | Line 30: | ||
| DICOM UPS IOD || ''(Procedure Performed)'' || DICOM UPS N-Get|| {Dx-Pull}, {Dy-Pull} || | | DICOM UPS IOD || ''(Procedure Performed)'' || DICOM UPS N-Get|| {Dx-Pull}, {Dy-Pull} || | ||
|- | |- | ||
− | | Performed Proc. || DICOM MPPS IOD || Images Stored || DICOM C-Store || { | + | | Performed Proc. || DICOM MPPS IOD || Images Stored || DICOM C-Store || {S1-Push} || |
|- | |- | ||
| Radiation Dose || DICOM SR Dose IOD || ''(Dose Stored)'' || DICOM C-Store || {D5-Push} || | | Radiation Dose || DICOM SR Dose IOD || ''(Dose Stored)'' || DICOM C-Store || {D5-Push} || |
Revision as of 00:03, 3 August 2007
<Return to the main Reporting Whitepaper page>
Artifact | Encoding | Transaction | Transport | Input/Output | |
---|---|---|---|---|---|
Patient Account | HL7 PV1 | Patient Update | (HL7 Msg) | {P1-Push} | |
Order | HL7 ORM | Placer Order Management | (HL7 Msg) | {O1-Push} | |
Worklist | DICOM MWL IOD | Modality Worklist Provided | DICOM MWM C-Find | {W1-Pull} | |
DICOM UPS IOD | (Query Worklist) | DICOM UPS C-Find | {W2-Pull} {W4-Pull} {W5-Pull} {W6-Pull} |
||
(Push Workitem) | DICOM UPS N-Create | {W2-Push} {W5-Push} {W6-Push} |
|||
Images | DICOM Image IODs | Images Stored | DICOM C-Store | {D3-Push}, {D7-Push} | |
Retrieve Images | DICOM C-Store | {D3-Pull} | |||
Performed Proc. | DICOM MPPS IOD | Modality Procedure Performed | DICOM N-Set | {D6-Push} | |
DICOM UPS IOD | (Procedure Performed) | DICOM UPS N-Get | {Dx-Pull}, {Dy-Pull} | ||
Performed Proc. | DICOM MPPS IOD | Images Stored | DICOM C-Store | {S1-Push} | |
Radiation Dose | DICOM SR Dose IOD | (Dose Stored) | DICOM C-Store | {D5-Push} | |
Procedure Log | DICOM SR PLog IOD | (Procedure Log Stored) | DICOM C-Store | {D6-Push} | |
Dictation Audio | ??? | (Audio Stored) | ??? | {R1-Push} | |
Radiology Report (Proto/Draft/Final) |
HL7 CDA | (D-Report Stored) | DICOM C-Store | {R2-Push}{R3-Push}{R4-Push} | |
(H-Report Stored) | (HL7-Msg) | {R4-Push}{R5-Push} | |||
History/Allergies/ Problems/Meds |
HL7 CDA-MS | ??? | ??? | {P2-Pull?} | |
Staff Schedule | HL7 ??? | Out of scope? | ??? | {H1} | |
Staff Certifications | HL7 ??? | <PWP> | ??? | {H2-Pull} |
Performed Proc. Details using HL7 DFT?
Lab Results
Pathology Results
Patient History Sheet
Tech Interview Sheet
Bill X12
<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.>>