Acquisition gateway - DICOM

This is a discussion on Acquisition gateway - DICOM ; Just when I was starting to understand what a PACS does, I was told I'll need an acqusition gateway. I asked does this come with the digital radiology unit being built for our animal hospital. Answer: no. Can a acquisition ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Acquisition gateway

  1. Acquisition gateway

    Just when I was starting to understand what a PACS does, I was told
    I'll need an acqusition gateway. I asked does this come with the
    digital radiology unit being built for our animal hospital. Answer: no.

    Can a acquisition gateway (which I think is the same as saying DICOM
    gateway?) be installed on the same server/machine as the PACS?

    Any recommendations for a Linux / open source acquisition gateway? If
    not any recommendations would be appreciated.

    Thanks.

    Steve Poe


  2. Re: Acquisition gateway

    Never heard of an acquisition gateway, but that means nothing.
    Normally your modality has a dicom interface ( at least the newer ones,
    if you are working digitally ) . Then you can connect your modality via
    your hospital network to your pacs, for example conquest, so your
    modality directly sends the images to your pacs. The pacs has a dicom
    server running, cause dicom server ist part of the pacs and the most
    workstationprograms. Thats all.


  3. Re: Acquisition gateway

    steve.poe@gmail.com wrote:
    > Just when I was starting to understand what a PACS does, I was told
    > I'll need an acqusition gateway. I asked does this come with the
    > digital radiology unit being built for our animal hospital. Answer: no.
    >
    > Can a acquisition gateway (which I think is the same as saying DICOM
    > gateway?) be installed on the same server/machine as the PACS?
    >
    > Any recommendations for a Linux / open source acquisition gateway? If
    > not any recommendations would be appreciated.


    Normally there is no need for any device interposed between a DICOM
    acquisition modality and a PACS.

    Some reasons why they are sometimes used:

    - the modality isn't DICOM at all, and needs something to convert
    some proprietary format into a DICOM dataset

    - the modality creates DICOM files but doesn't know how to do the
    DICOM network protocol to get them to the PACS (C-STORE)

    - the modality creates DICOM but doesn't do a very good job and the
    datasets contain errors that need to be "repaired" first

    - the PACS makes unwarranted assumptions about the content or order
    or timing of arrival of the images from the modality, and they need
    to be cached temporarily and "re-sorted" before sending on to the
    PACS - another reason to do this is to mess with the grayscale or
    apply different lookup tables in the case of projection radiography
    images

    - the connection between the modality and the PACS is slow or insecure
    and so compression or encryption are needed between them

    - the modality doesn't support Modality Worklist, and hence the
    human entered identifiers may be incorrect and the Study Instance
    UIDs are not those the PACS expects - a filter between the modality
    and the PACS can "guess" which worklist or patient the images belong
    to and coerce the attributes into the right values or form, before
    sending them to the PACS - this might be done with a gateway that
    reads worklists or just listens to ADT feeds

    - likewise, the modality doesn't support Storage Commitment or
    Modality Performed Procedure Step, and it is desired that these
    be simulated

    - the images need to be QC'd by a human operator before making them
    available, and one doesn't want to take the time to do this on the
    modality console, and there is no PACS workflow to segregate such
    images - hence an intermediate QC station makes sense

    - the modality gets bogged down waiting for C-STORE responses
    from individual image storage operations to the PACS, and so
    throughput can be improved by caching these in a gateway that
    does the waiting for the PACS to catch up, instead of the modality.

    I am sure there are many others.

    But the bottom line is that for most properly implemented DICOM
    modalities, no gateway should be necessary for basic functionality.

    To properly answer your question, you need to ask your modality
    vendor why they think a gateway is necessary.

    You can begin by asking them to give you a copy of their DICOM
    Conformance Statement for the modality, which you can analyze
    to assess whether or not a gateway is necessary.

    David




  4. Re: Acquisition gateway

    David,

    Thanks for your feedback. Part of my challenge is I don't know what I
    am suppose to know.

    We have a vendor developing the digital x-ray plate unit from scratch
    for us. They said we'll need an aquisition gateway/station. By default,
    the image created will be a 2048x2486x16 TIFF image.

    I am thinking the vendor has DICOM conformance further down the list
    of priorities. I think this is why their asking us to create a gateway.
    I could be wrong.

    Steve Poe


  5. Re: Acquisition gateway

    If your vendor is developing the digital x-ray plate unit from scratch
    for you without the implementation of a dicom interface and ignoring
    the dicom conformance statements, there must be someting wrong with
    that guy. Thats standard now.And images, that will be created in tiff
    format by default sounds a lttle bit strange to me.


  6. Re: Acquisition gateway

    Without giving way confidential information, the vendor advised the
    following:

    "Steve,
    Our detector is just a USB peripheral to a PC (a.k.a acquisition
    station). It simply outputs a 16bit TIFF (see my previous email). The
    "acquisition software" (running on the acquisition station) imports
    that 16bit TIFF image, displays it, manipulates it and adds all the
    pet/vet's info in order to "dicomize" it (i.e. save it in a Dicom
    format). ... these programs will work:
    http://www.desacc.com/products/djpro/index.html
    http://www.pacsgear.com/products_psf_overview.html
    http://www.accusoft.com/imaging/imagegear/imagegear_functions/medical.asp"


    It's my impression, and I could be wrong, that after the hardware
    design phase of the plate is done, the next phase is dicom compliance.
    Although, I have not specifically asked the vendor this question yet. I
    know this not a short-term project.

    Steve


  7. Re: Acquisition gateway

    It really depends on what you're planning to use the detector for, and
    how what you expect from the images.

    There are plenty of applications where a portable digital xray detector
    which outputs TIFF images would be perfectly acceptable - e.g. xraying
    mechanical parts. There's even mapping to DICOM attributes by the
    American Society for Testing and Materials. However, the "M" in DICOM
    is for "in Medicine" and it is intended to be the primary usage.

    Acquisition gateway software is most likely going to give you a minimal
    dicom implementation. eg DICOM Secondary Capture but not CR or DICOM
    Digital Xray. You simply won't get enough information through the TIFF
    file (unless they've stuffed a bunch of information into custom tags in
    the TIFF file) to enable you or the acquistion gateway to build a valid
    CR or DX object. Even if they do stuff the extra information into the
    TIFF attributes, not every acquisition gateway is going to be able to
    pull them out and put them into DICOM attributes. Speaking of that, not
    every acquisition gateway is going to handle 16bit pixel values. Many
    only support 8-bit or 24-bit (8-bits per color) image data.

    Anyway, the fact that you're asking on the DICOM newsgroup has an
    implicit message that you intend to use this "from scratch" sensor in a
    medical/clinical domain. Most of us would have a lot of doubts for that
    usage, not the least being patient safety/fda regulatory issues.
    Assuming you've covered that base, DICOM secondary capture images may
    meet your needs, after all they've served the film scanning community
    for years. If you literally, only want to see the patient name,
    procedure name, and the xray pixel data, it may meet your needs.

    An acquisition gateway will likely do two things for you/your vendor -
    and AG with a modality worklist SCU can pull patient demographics and
    basic procedure information from a worklist which the AG will build
    into the DICOM image headers (otherwise you'll have to enter that data
    by hand). It will also synthesize unique identifiers (UIDs) for you and
    insert them into the proper places into the DICOM header. It may (or
    may not) provide you a convenient interface for organizing TIFF images
    into related sets (DICOM Studies, DICOM Series) and assignging the UID
    values appropriately. It will not give you detailed information
    specific to the acquisition: patient orientation, xray collimator
    distance from the sensor, e xray tube current, gantry title, data/time
    of the acquisition, patient orientation, and whole raft of other
    attributes that are normally available because the xray detector is
    part of an integrated imaging modality device

    Another point that may have escaped you. Most scintillator arrays or
    other direct xray detecting have a very different intensity response
    curves than x-ray film. A very important function, and highly
    proprietary aspect, of CR/DX modality application consoles are the
    algorithms which convert the xray intensity values (or scintillator
    optical values) into a sort of simulated film response. These
    algorithms use a lot of those things previously mentioned - e.g.
    distance of the sensor from xray source -- and values estimating the
    thickness of patient tissue the xrays have had to traverse (different
    coefficients for pediatric and adult exams) to make images which "look
    like" a great film xray image. These algorithms generally are not
    going to be standard features on your run of the mill acquisition
    gateway. If the sensor vendor isn't supplying these algorithms, you may
    be very unhappy with the results you get from the device

    Your vendor probably has a really nice device, and a neat idea on how
    to make a portable digital xray sensor; but it sounds like they have a
    ways to go before its ready to be used as a clinical device. They are
    either being naive or disingenuous with you. Be careful you don't walk
    down the garden path and end up getting yourself sued because you were
    the one who actually made it a medical device by putting the
    non-medical sensor device together with the acquisition gateway, and
    using it in clinical practice.


  8. Re: Acquisition gateway

    Eric,

    In everything you said (which some is over my head since I am learning
    here), there is a reason why we're an animal hospital and we're a
    volunteer test case. Outside of medication dispersement, FDA has not
    regulation of equipment in animal healthcare unlike human healthcare.

    Initially, I only care about the patient name, account number, etc. but
    I know the co-founder of the hospital wants to set kpv values and
    information that is beyond my understaning but I'll need to get
    familiar with.

    The vendor has expressed we're talking "baby steps" so I don't think
    leaving anytime soon nor are we ready to go live.

    Thanks again for your feedback.

    Steve

    Our patient demographics are stored on a database on another server
    (more work for me), but the goal is to minimize data entry.

    I would only guess/assume if the vendor ultimate market is the human
    side, they're not going to sell any units with DICOM compliance.


  9. Re: Acquisition gateway

    Steve

    Ok, I said a mouthful, some of it with rocks in my mouth. Not always
    careful enough when I go back and edit previously written sentences.

    >From you vendor's words:
    >Our detector is just a USB peripheral to a PC (a.k.a acquisition
    >station). It simply outputs a 16bit TIFF (see my previous email). The
    >"acquisition software" (running on the acquisition station) imports
    >that 16bit TIFF image, displays it, manipulates it and adds all the
    >pet/vet's info in order to "dicomize" it (i.e. save it in a Dicom
    >format). ... these programs will work:


    TIFF is a standard image format often seen used in document scanners.
    When he says, 16bit TIFF, it means each pixel is stored as a 16bit
    value (0 - 64k). This is NOT typical. Most scanners only store 8 bits
    per pixel, and quite a few acquisition stations are only equipped to
    handle 8 bit data as a result. You may find one that does. I note he
    cites PACSGear which has a device is intended to for hooking up paper
    scanners and turning them into DICOM secondary capture objects.
    Basically they take data from a standard TWAIN scanner interface and
    turn it into a DICOM object, a minimal extra data dicom object.

    The pets/vets info he references is the "patient demographics and
    procedure information" I cited. One thing to beware of, there are not
    currently standard attributes typical in veterinary practice. So, you
    won't find acquistion stations that will store both the "patient name"
    (pet) and the owner name. There is a veterinary medicine working group
    developing some attributes right now. but in the mean time you're going
    to have kludge something to get all the attributes you would normally
    capture into the DICOM object.

    I'm not sure what's riding on your question -- ie are you just trying
    to figure out what you need to buy to work with an existing product
    that has been previously tested with this device (or others like it).
    Or, is this vendor telling you to go buy an acquistion station because
    "it should work" just like a USB TWAIN scanner? If its the latter, I'd
    hold the vendor to his word - tell him to buy one, demonstrate it works
    to your satisfaction and you'll reimburse him for the cost. Your
    terminology building a sensor "from scratch" makes it sound a lot like
    the vendor is only doing half the job, and its your problem to make the
    sensor work with the acquisition station. That should not be the case.
    If he's building the device, he should be able to demonstrate its
    ability to work. You might also call up the vendors he recommended and
    ask them for a trial license, tell them you're trying to validate with
    a new veterinary xray sensor. They might be willing to provide free
    trial if it opens a new market niche for them with your vendor


  10. Re: Acquisition gateway

    Eric,

    Thanks for the feedback. Yes, I am trying to figure out the pieces of
    the puzzle. But, the vendor is not supplying an aquisition station in
    this deal (to my understanding).

    Before we met this vendor, we have been looking at Medweb, Eklin, Sound
    Technologies for a PACS solution. It was my thinking that the DR unit
    can connect directly via network to the PACS. These vendors mentioned
    having a "aquisition gateway" which I thought came with the DR unit,
    and maybe they do, but this vendor is promising the plate if we could
    be their case study.

    I have not physically seen their setup, which is on my things to do
    list, then I'll have a better idea of what their supplying.

    We have made it clear to the vendor we need DICOM compliance. We're
    aware that veterinary fields will not make into DICOM until 2007. We
    just enter in the animal's name with the owner's last name with the
    account number which connects to the owner listed in our database.

    Steve


  11. Re: Acquisition gateway

    Eric,

    I have already told the main veterinarian that getting our pilot PACS
    server running was the easy part. I am glad he doesn't think this going
    to be up and running in a month.

    As we speak, I am plowing through "PACS and Imaging Informatics:Basic
    Principles and Applications" from H.K. Huang.

    The lead veterinarian did not want to purchase a pre-packaged a PACS.
    The idea of spending $30-50K in software did not interest him. Since I
    am here, he's hoping we can do most of this with open source tools.

    I think we can build it, but I equate it to building a car or airplane
    but not really knowing how each piece functions. At the point of
    intergrating the PACS with the DR and the ability to pull client
    information to minimize data entry to imprint on the DICOM image.

    When we get past the DR intergration, then the next phase will our
    ultrasound machine and digital dental x-ray.

    In each phase, I am hoping to web-ify, but again, I don't know enough
    how the pieces will fit together. I do see the need for DICOM
    consulting down the road.

    Steve


+ Reply to Thread