Accession number field length - DICOM

This is a discussion on Accession number field length - DICOM ; We have requested to increase the accession number field size on our PACS. However, our PACS vendor has stated that the length of the accession number field is 16 characters, which is a DICOM standard and cannot be altered. I ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Accession number field length

  1. Accession number field length

    We have requested to increase the accession number field size on our
    PACS. However, our PACS vendor has stated that the length of the
    accession number field is 16 characters, which is a DICOM standard and
    cannot be altered. I cannot find any standard to support this, does
    anyone know if the field size of 16 characters for the accession
    number is a DICOM standard and cannot be altered?

  2. Re: Accession number field length


    "John" wrote in message
    news:23c00d1d.0411161505.5f463791@posting.google.c om...
    > We have requested to increase the accession number field size on our
    > PACS. However, our PACS vendor has stated that the length of the
    > accession number field is 16 characters, which is a DICOM standard and
    > cannot be altered. I cannot find any standard to support this, does
    > anyone know if the field size of 16 characters for the accession
    > number is a DICOM standard and cannot be altered?


    This is correct. The 2004 standard states Accession Number has value
    representation SH, look in PS3.6-2004, and then in PS3.5-2004 you find that
    value representation is 16 characters maximum. You can get the complete
    standard online if needed at http://medical.nema.org/

    Ralph



  3. Re: Accession number field length

    > "John" wrote in message
    > news:23c00d1d.0411161505.5f463791@posting.google.c om...
    >
    >>We have requested to increase the accession number field size on our
    >>PACS. However, our PACS vendor has stated that the length of the
    >>accession number field is 16 characters, which is a DICOM standard and
    >>cannot be altered. I cannot find any standard to support this, does
    >>anyone know if the field size of 16 characters for the accession
    >>number is a DICOM standard and cannot be altered?


    The limit on Accession Number to 16 characters is essentially immutable.

    It may have been short sighted to restrict Accession Number to such
    a short string, but unfortunately that limit is supposedly hard-wired
    into databases and user interfaces for PACS and modalities, and has been
    for such a long time that changing it now is impractical.

    The VA asked for this change to the standard several years ago and
    it was rejected at the time for the same reason. I do not recall how
    they ended up working around this issue.

    This is usually more of a problem for accession numbers that are
    generated by concatenating various existing identifiers, like SSN
    plus a disambiguator or similar, rather than simply exhausting the
    possibilities for a 16 character string. Even if one restricted
    one self to upper case letters and digits, 16 chars provides for a space
    of 36^16, which is almost 7.96E+24 possible values, which is quite large.
    Indeed since the character repertoire is not limited to numbers and
    upper case letters, the actual space is huge, but there are problems
    with human readability using more than that.

    So I guess you have to push back on whoever is asking for the increase
    in field length and ask them why, and what alternatives they can use
    that fit in the available 16 characters.

    It simply is not possible to retool every modality, worklist broker,
    RIS and PACS you may encounter now or in the future to handle a
    longer field.

    It would theoretically be possible to add a new field to DICOM to
    augment or replace Accession Number, but it could only be optional
    for existing services, would not likely to be universally implemented,
    and would not be compatible with the installed base. I.e. impractical.

    This is probably something well beyond IHE's ability to solve either.

    Regardless, I would caution against trying to force your PACS vendor to
    acquiesce and violate the standard, since then the problem will be
    propagated to the modalities receiving worklists, and they will likely
    behave badly. As you know, you have little chance of influencing the
    implementation of the modalities.

    David


  4. Re: Accession number field length

    IHE maps the Accession Number to the Filler Order Entity
    [IHE Technical Framework, vol. I: Integration Profiles
    3.4.3 Scheduled Workflow Information Model (Page 60f)].
    So (0008,0050) "Accession Number" and (0040,2017) "Filler Order Number /
    Imaging Service Request" refers the same entity. And the value of
    (0040,2017) "Filler Order Number / Imaging Service Request"
    is not limited to 16 but 64 characters (Value Representation = LO).

    Currently, most modalitities fetch only the Accession Number from
    Modality Worklists and put it into generated objects/images, but not the
    Attribute (0040,2017) Filler Order Number - which obstructs the use of
    (0040,2017) Filler Order Number as replacement of (0008,0050) Accession
    Number.

    gunter


    David Clunie wrote:
    > > "John" wrote in message
    > > news:23c00d1d.0411161505.5f463791@posting.google.c om...
    > >
    > >>We have requested to increase the accession number field size on our
    > >>PACS. However, our PACS vendor has stated that the length of the
    > >>accession number field is 16 characters, which is a DICOM standard and
    > >>cannot be altered. I cannot find any standard to support this, does
    > >>anyone know if the field size of 16 characters for the accession
    > >>number is a DICOM standard and cannot be altered?

    >
    > The limit on Accession Number to 16 characters is essentially immutable.
    >
    > It may have been short sighted to restrict Accession Number to such
    > a short string, but unfortunately that limit is supposedly hard-wired
    > into databases and user interfaces for PACS and modalities, and has been
    > for such a long time that changing it now is impractical.
    >
    > The VA asked for this change to the standard several years ago and
    > it was rejected at the time for the same reason. I do not recall how
    > they ended up working around this issue.
    >
    > This is usually more of a problem for accession numbers that are
    > generated by concatenating various existing identifiers, like SSN
    > plus a disambiguator or similar, rather than simply exhausting the
    > possibilities for a 16 character string. Even if one restricted
    > one self to upper case letters and digits, 16 chars provides for a space
    > of 36^16, which is almost 7.96E+24 possible values, which is quite large.
    > Indeed since the character repertoire is not limited to numbers and
    > upper case letters, the actual space is huge, but there are problems
    > with human readability using more than that.
    >
    > So I guess you have to push back on whoever is asking for the increase
    > in field length and ask them why, and what alternatives they can use
    > that fit in the available 16 characters.
    >
    > It simply is not possible to retool every modality, worklist broker,
    > RIS and PACS you may encounter now or in the future to handle a
    > longer field.
    >
    > It would theoretically be possible to add a new field to DICOM to
    > augment or replace Accession Number, but it could only be optional
    > for existing services, would not likely to be universally implemented,
    > and would not be compatible with the installed base. I.e. impractical.
    >
    > This is probably something well beyond IHE's ability to solve either.
    >
    > Regardless, I would caution against trying to force your PACS vendor to
    > acquiesce and violate the standard, since then the problem will be
    > propagated to the modalities receiving worklists, and they will likely
    > behave badly. As you know, you have little chance of influencing the
    > implementation of the modalities.
    >
    > David
    >


+ Reply to Thread