RSNA 2004 reflection, a SR question - DICOM

This is a discussion on RSNA 2004 reflection, a SR question - DICOM ; Hi all, At the RSNA 2004 exhibition, numerous vendors presented dedicated workstations/software for interpretation of ultrasound, cardiology etc with integrated report templates to speed up the workflow by allowing measurements to be automatically imported inte the workstations own report template. ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: RSNA 2004 reflection, a SR question

  1. RSNA 2004 reflection, a SR question

    Hi all,

    At the RSNA 2004 exhibition, numerous vendors presented dedicated
    workstations/software for interpretation of ultrasound, cardiology etc
    with integrated report templates to speed up the workflow by allowing
    measurements to be automatically imported inte the workstations own
    report template. Be means of creating the report in a minimum of time
    this is a very appealing workflow, and it seems as every vendor
    incorporating this possibility also allows the created report to be
    sent to PACS as a DICOM SR object.

    So- here's my question:
    By creating the report in the workstation, you bypass the RIS
    reporting tool. And you wouldn't like to have a number of bookings in
    the RIS missing the report as the exams has been performed and a
    report created (at least I wouldn't). What's your strategy concerning
    this? Is there a standard method defined anywhere (IHE framwork or
    other) for the RIS to get access to the data from the SR object?

    I'd highly appreciate your thoughts about this.

    Thanks,

    Anders Eriksson
    Karolinska University Hospital, Stockholm

  2. Re: RSNA 2004 reflection, a SR question

    Anders Eriksson wrote:
    > [...]
    > By creating the report in the workstation, you bypass the RIS
    > reporting tool. And you wouldn't like to have a number of bookings in
    > the RIS missing the report as the exams has been performed and a
    > report created (at least I wouldn't). What's your strategy concerning
    > this? Is there a standard method defined anywhere (IHE framwork or
    > other) for the RIS to get access to the data from the SR object?


    IHE has indeed covered this topic with the rather recent "Reporting
    Workflow" integration profile that is included in the IHE Radiology
    Technical Framework 5.5. Basically the answer that IHE gives to your
    question is the use of the DICOM General Purpose Worklist service
    which allows the RIS to function as a general workflow tool that
    includes not only image generation but also reporting and image
    processing task. DICOM General Purpose worklists and PPS messages
    allow for a "synchronization" between the RIS and the reporting
    workstations.

    Regards,
    Marco Eichelberg
    OFFIS

  3. Re: RSNA 2004 reflection, a SR question

    Anders,

    IHE Technical Framework (rev 5.5) defined the Reporting Workflow
    to keep track the schedule, and status of various reporting task.
    There is another profile called Simple Image and Numeric Report (SINR)
    Profile which mostly addresses the content of the report.

    For reporting workflow, read IHE Technical Framework Vol I section 13
    pg. 130.

    The Report Manager should support incoming data such as MPPS Completed
    for Image Aquisitions and create Reporting Worklist Task. After a
    report task scheduled, Report Creator (Image Display) then create a
    report (Report Workitem PPS INPROGRESS) and send it to PACS (Report
    Manager) as DICOM SR (Report Workitem PPS COMPLETED). After received,
    the Report Manager can translate forward the report to RIS via HL7
    defined at Structure Report Export.

    Check out also a detail transaction of Structured Report Export (Vol II
    4.28). This transaction is addressed the needs of storing verified
    report (in DICOM SR) to Enterprise Report Repository in HL7. (IHE TF
    also defined HL7 and DICOM Mapping consideration at Vol II).

    Dominick Anggara
    IDX Inc. (www.idx.com)
    Winston Salem - Structured Reporting


  4. Re: RSNA 2004 reflection, a SR question


    Anders Eriksson wrote:
    > Hi all,
    >
    > At the RSNA 2004 exhibition, numerous vendors presented dedicated
    > workstations/software for interpretation of ultrasound, cardiology

    etc
    > with integrated report templates to speed up the workflow by allowing
    > measurements to be automatically imported inte the workstations own
    > report template. Be means of creating the report in a minimum of time
    > this is a very appealing workflow, and it seems as every vendor
    > incorporating this possibility also allows the created report to be
    > sent to PACS as a DICOM SR object.
    >
    > So- here's my question:
    > By creating the report in the workstation, you bypass the RIS
    > reporting tool. And you wouldn't like to have a number of bookings in
    > the RIS missing the report as the exams has been performed and a
    > report created (at least I wouldn't). What's your strategy concerning
    > this? Is there a standard method defined anywhere (IHE framwork or
    > other) for the RIS to get access to the data from the SR object?
    >
    > I'd highly appreciate your thoughts about this.
    >
    > Thanks,
    >
    > Anders Eriksson
    > Karolinska University Hospital, Stockholm



    There are defferent types of reports, not all of them generated or even
    handled in the RIS today. Two high level categories of reports are
    procedure reports and diagnostic reports. You cited applications for
    ultrasound and cardiology. Three recent additions to the DICOM standard
    are SOP classes and report templates for ultrasound ob/gyn reports,
    vascular reports, and cardiology procedure reports. These reports
    primarily substitute for measurements and readings that a technician
    infers or derives from applications running on the modality or modality
    associated workstation. For example, in ultrasound OB examinations
    there are standard measurements for the fetal cranial diameter and
    femur length at the 1st and 2nd trimester examination. With spatial
    measurements included in the image metadata, it has been a relatively
    straightforward process to derive these measurements with software
    tools on a workstation. Taking these measurements is also a standard
    procedure for the sonotech; but after taking the measurements how are
    they communicated and stored? In the absence of a DICOM SR, they are a)
    handwritten on paper; b) burned in as annotations on the original or a
    derived image; or c) captured in a standards-based or proprietary
    standalone object (e.g. a gsps annotation. The point of the SR was/is
    to allow these measurements to be captured, transferred, stored, and
    presented/displayed in an interoperable fashion across multiple
    vendor's equipment in a manner which preserves and precisely represents
    the original semantic content of the original generator. They are a
    "reports" because they contain textual information and are derived from
    the information in the original images (as opposed to having been part
    of the sensor acquisition); but they are not "reports" in the sense of
    the radiologist's diagnostic report.

    >From a workflow point of view, they are treated much the same as the

    images in original exam. The DICOM SR format allows this auxilary
    information which would previously have been routed to the radiologist
    via a paper process or via a presentation only, to now be routed in a
    semantically preserved form where the information can be easily
    transferred into another format, such as the radiologist's or
    cardiologist's actual diagnostic report. And, yes, those diagnostic
    reports could be coded as DICOM SR objects, but currently there is lack
    of agreed upon report templates for diagnostic reports.

    The IHE has defined a general workflow for the creation, verification,
    and storage in a repository but no to the degree that you could expect
    independent workstations to be able to generate reports which would
    close the workflow loops in most existing RIS applications. That day is
    coming and work is in progress, but currently most SR implementations
    are for procedure or CAD applications which are treated as additional
    information objects contributing the report which gets generated on the
    traditional reporting platform - eg the RIS


+ Reply to Thread