Zero Length Accession Number for Unscheduled PPS OK? - DICOM

This is a discussion on Zero Length Accession Number for Unscheduled PPS OK? - DICOM ; I would like to get opinions from others in the DICOM community about the IHE requirement that a zero length Accession Number (0008,0050) be created when a Performed Procedure Step (PPS) is unscheduled. See IHE Technical Framework, vol. II: Transactions, ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Zero Length Accession Number for Unscheduled PPS OK?

  1. Zero Length Accession Number for Unscheduled PPS OK?

    I would like to get opinions from others in the DICOM community about
    the IHE requirement that a zero length Accession Number (0008,0050) be
    created when a Performed Procedure Step (PPS) is unscheduled. See IHE
    Technical Framework, vol. II: Transactions, Rev 5.5, Appendix A, Table
    A-1, Note (IHE-4).

    My concern is that not allowing the user to enter an Accession Number
    for unscheduled PPS may not fit the workflow of some hospitals or
    clinics. For example, assume that a hospital is having networking
    problems with their HIS or they are changing the HIS software and are
    experiencing problems with Modality Worklist and MPPS. However, they
    are able to generate paper orders with Accession Numbers and want the
    Accession Numbers entered manually for every PPS.

    Is the IHE requirement OK or will it cause problems in some hospitals?

    Regards,
    Clare Anderson
    Siemens Medical Solutions, Ultrasound Division


  2. Re: Zero Length Accession Number for Unscheduled PPS OK?


    Clare wrote:
    > I would like to get opinions from others in the DICOM community about
    > the IHE requirement that a zero length Accession Number (0008,0050)

    be
    > created when a Performed Procedure Step (PPS) is unscheduled. See

    IHE
    > Technical Framework, vol. II: Transactions, Rev 5.5, Appendix A,

    Table
    > A-1, Note (IHE-4).
    >
    > My concern is that not allowing the user to enter an Accession Number
    > for unscheduled PPS may not fit the workflow of some hospitals or
    > clinics. For example, assume that a hospital is having networking
    > problems with their HIS or they are changing the HIS software and are
    > experiencing problems with Modality Worklist and MPPS. However, they
    > are able to generate paper orders with Accession Numbers and want the
    > Accession Numbers entered manually for every PPS.
    >
    > Is the IHE requirement OK or will it cause problems in some

    hospitals?
    >
    > Regards,
    > Clare Anderson
    > Siemens Medical Solutions, Ultrasound Division



    OK, I admit my example was flawed. However, I still think there are
    times when a hospital would experience problems and want all procedure
    steps to be treated as unscheduled and the Accession Number to be
    entered manually. My understanding of the IHE rule is that they never
    want an Accession Number to be sent in the MPPS N-Create-Req for the
    unscheduled case.

    Clare


  3. Re: Zero Length Accession Number for Unscheduled PPS OK?


    OK my example is flawed, but is it really desirable to always send a
    zero length Accession Number for unscheduled PPS? I am relictant to
    limit the user's options unless it is clearly the correct
    implementation. It isn't clear to me that sending a zero length
    Accession Number for unscheduled PPS is always desirable.

    Is Accession Number the trigger for Patient Information Reconcillation?

    Does anyone have experience either way with this?

    Regards,
    Clare


  4. Re: Zero Length Accession Number for Unscheduled PPS OK?

    Hi Clare,

    I am new to DICOM but from what I know, hospitals usually use the
    Accession number for billing. Hence even if the PPS is unscheduled, the
    only way they will get money out of that will be by having an accession
    number to put into their billing workflow. So I think it might be
    useful to let them enter it manually, though I can see your hesitation,
    because the more you let the user do the more ways they come up with to
    break the system and then blame us :-)

    Hope that helps atleast to some extent.
    Akshay


+ Reply to Thread