"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

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

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
>