DICOM Requirements for Modality Bid Specs Ris

Document Sample
DICOM Requirements for Modality Bid Specs Ris Powered By Docstoc
					                     DICOM Requirements for Modality Bid Specs

When you order new modalities for imaging that you want to connect to PACS, the
following items should be specified in the bid. Please see the explanations at the bottom
of the document so that you understand why these need to be in the bid. If this is not
specified, the vendor will charge you to add these capabilities after the fact.

Updated: 06/18/07       Bill Gregg

------------------ Copy appropriate text below this line into your bid spec ---------------

                             DICOM/HL7/IHE Requirements

In order to facilitate the bid process, the DICOM Conformance Statement, applicable IHE
Integration Profiles, and the Manufacturers Discloser Statement for Medical Device
Security (MDS2) should be forwarded to the PACS Administrator at LSUHSC-S early in
your process. Bid’s that do not provide this information will not be accepted. Each
modality will have a different set of requirements encompassed within the points below.
Each request from LSUHSC-S should have attached to this document a copy of these
requirements in a spreadsheet format. If these spreadsheets are included they will define
the specific functionality required, otherwise this document will define the requirements.
These requirements will be matched up with the vendors statements provided above to
determine if the modality bid meets the LSUHSC-S requirements.

    1. The modality must be DICOM (Digital Imaging in Communications and
       Medicine) compliant, provide at a minimum Level 2 conformance, and be able to
       function with other DICOM compliant modalities and systems within LSUHSC-
       S. The intent is to provide maximum automation for the institution utilizing
       DICOM standards. This includes specifically the institutions GE PACS (Picture
       Archiving and Communications System), and any other DICOM equipment
       specified in the bid. Functionality at a minimum includes DICOM Storage Service
       Class User (SCU) and DICOM Verification Service Class User and Provider
       (SCU and SCP) capability. These classes should be current and appropriate for
       the modality, and if requirements specify connection to an older system, should
       include any potential ‘retired’ SOP (Service Object Pairs) the older modality may
       require. If the modality does not yet have the capabilities below, they must be
       installed at no additional charge within one year from purchase. These items must
       be clearly stated in the bid specifications, along with projected time frames for
    2. The modality must be able to perform DICOM Modality Work List Information
       Model Find functions so that patient orders can be selected from a worklist
       provided by PACS/RIS (Radiology Information System), rather than requiring
       manual entry by the technologist. The worklists will be provided via the Mitra
       broker. For this bid there is a cost for a license pack to access the worklist from
       the modality for which the bid vendor is responsible. The vendor should negotiate
       with GE to purchase the applicable MWL license pack.
3. The modality must be able to perform DICOM Modality Performed Procedure
   Step functions, so that exam progress status can be automatically sent back to
   PACS/RIS, and DICOM Storage Commitment.
4. The modality must be able to perform DICOM Query/Retrieve functions as a
   Service Class User for all appropriate image sets to allow for retrieval of prior
   studies for comparison at the modality.
5. The modality must be able to perform DICOM Print as a Service Class User for
   all appropriate image sets, and must work with LSUHSC-S DICOM Print servers.
6. LSUHSC-S currently has GE’s PACS system (Centricity 2.0), and Siemens/SMS
   RIS system (v23). It is the vendor’s responsibility to ensure that images can be
   stored, retrieved and properly displayed from PACS, and that all requested
   DICOM/HL7/IHE functions work with the appropriate LSUHSC-S systems. This
   includes any additional licenses, fees and service required by these vendors to
   connect the modality and provide the functionality described. There will be a
   DICOM connection fee to connect the modality to the GE PACS for which the bid
   vendor will be responsible. The vendor should negotiate with GE to cover this
   connection fee. Payment will be made pending LSUHSC-S verification of these
   functions. LSUHSC-S’s unidirectional PACS broker currently prohibits DICOM
   MPPS from occurring, but once the ability to do bi-directional communication
   with the RIS is in place, this MPPS SOP class must be implemented by the
   vendor. If this connection does not work due to the vendor’s product not properly
   implementing the DICOM standard, it must be fixed. It is the intention of this bid
   to ensure a complete installation, and that there will not be any ‘gaps’ left to
   LSUHSC-S to pay for outside of the bid to make the systems work as intended.
7. Once the modality is installed, the vendor will work with LSUHSC-S to provide
   validation testing before production use to ensure proper exchange of intended
8. The vendor must be a participant in the IHE (Integrating the Healthcare
   Enterprise) initiative. A current IHE Integration Statement must be provided prior
   to the bid. It is LSUHSC-S intent to utilize IHE principles to support the
   integration of systems in the healthcare enterprise. The vendor must be working in
   the same direction in order to be considered for this bid. There are currently a
   number of Integration Profile specifications, with varied degree of support from
   Vendors. Ultimately, all Integration Profiles should be a standard part of a
   Vendors offer. The specific profiles are listed below, and are required if
   applicable to the system being bid. If the Vendor does not currently support
   applicable profiles, they must be made available upon Vendor implementation
   (within one year from purchase) at no extra charge to LSUHSC-S. The vendor
   must provide User Authentication/Access Control at the device, as well as node
   authentication and exportable audit logs in the IHE Audit Trail and Node
   Authentication (ATNA) format. There must be an ability to synchronize the clock
   on the device with a central clock specified by LSUHSC-S.
        a. Patient Information Reconciliation (PIR)
        b. Scheduled Workflow (SWF)
        c. Presentation of Grouped Procedures (PGP)
        d. Post Processing Workflow (PWF)
           e.   Reporting Workflow (RPW)
           f.   Charge Posting (CP)
           g.   Consistent Presentation of Images (CPI)
           h.   Evidence Documents (ED)
           i.   Key Image Notes (KIN)
           j.   Simple Image and Numeric Reports (SINR)
           k.   Access to Radiology Information (ARI)
           l.   Portable Data for Imaging (PDI)
           m.   Import Reconciliation Workflow (IRWF)
           n.   Audit Trail and Node Authentication (ATNA)
           o.   Nuclear Medicine Image (NMI)
           p.   Mammography Image (MMI)
           q.   Image Fusion (IF)
           r.   Teaching File and Clinical Trial Export (TCT)
           s.   Cross Enterprise Document Sharing for Imaging

   9. If the modality provides storage to removable devices (DVD or MOD), this
      storage must comply with the DICOM Part 10 Media Interchange standards and
      the IHE Portable Data for Imaging (PDI) profile. To insure compliance with
      LSUHSC-S HIPAA policy, the storage mechanism must at least have the option
      to remove Identifiable Healthcare Information from the image sets that will be
      transferred via this mechanism, and all creation functions must be logged
      according to the IHE ATNA profile.

Operating System and Software Patches
The vendor must provide critical (security or operational) patches on a timely basis,
including the process of FDA approval. If the system is affected by an attack on an
unpatched (one that has a patch available for it but has not been installed pending
approval by the vendor) security hole, it is the vendors responsibility to bring the system
back to a functional state within the emergency response time specified under service.

Network requirements
Network connections should be located within 15 feet of the console. The bid system
should support 100mbps (100BaseT) network speeds. 1000mbps network speed is
preferred, particularly for modalities that create large data sets, such as multi-slice CT.
The LSUHSC-S PACS network shall be segmented from the rest of the hospital network,
and utilize category 5e cables for all installations. Network jacks must be 8 pin modular
(RJ45). The bid system should be connected to the network via patch cord connection to
the facility infrastructure. LSUHSC-S will provide AE Titles, IP address, default router
IP address, and subnet mask for each system installed.

Hardware requirements
All computer hardware and operating systems must be current versions. For Windows at
this time that would be Windows XP Professional, NOT Vista. If a vendor is currently
utilizing an older operating system, the system must be upgraded within a year to the
current version of the operating system.
----------------------- Copy text above this line into your bid spec ---------------------

----------------------- Omit the descriptive text below from bid -------------------------

Some description is necessary to understand these items.

The items in the introductory paragraph are of utmost importance, and must be required
for every bid. If we do not do this we are making a blind purchase. The DICOM standard
is not a simple issue, and it is necessary to include the PACS Administrator early in the
process for creating the bid. It takes time and understanding to properly create the desired
specifications. The IHE Profiles ensure that the modality properly uses these standards to
accomplish desired goals. It is extremely important that the customer help the vendor to
comply with standards and frameworks. If we do not ensure the proper functionality in
the bid, it could either cost us significant money or lack of capability in the future. If we
can not get this information from the vendor, we must ensure that their product can not be
purchased. This can be done by utilizing the requirements spreadsheet prepared by the
PACS Administrator. If there is nothing from the vendor to compare it to, it does not
qualify. Consequently, every modality bid should have this, which requires involvement
well before the bid is let.

The Manufacturers Disclosure Statement for Medical Device Security is fairly new, but is
necessary to enable us to understand what the vendor provides, and also to push them to
fully provide mechanisms necessary for proper HIPAA security implementation.

Item 1 is pretty standard DICOM compliance stuff, and should be in every bid.

Item 2 ensures that we can use worklists on the modality, and not have to enter patient
information manually. This is a must.

Item 3 is not something we can make use of at this time, but should be able to use
somewhere down the line. This, like item 2, is a workflow enhancing function, as it
allows the device to automatically send start procedure and end procedure steps to the
RIS. This frees the technologist from having to manually track these steps. We need a bi-
directional, or brokerless (the PACS Broker is what transmits HL7 ADT and report
information from the RIS to the PACS) environment to be able to do this. Currently we
can only receive information from RIS, so the PPS function has no way to report back to
the RIS. In the future this should evolve. The bottom line here is that some vendors may
not have implemented this yet (all should as time goes on), and to reduce costs you may
need to leave this out. I strongly recommend all modalities we purchase have this
function, even though the vendor may not be able to implement it at this time.

DICOM Storage Commitment enables the PACS server to tell the modality that it has
taken charge of storing the exam, and has it committed. The modality can then delete the
study from its drive to make way for more exams. What we would ultimately like to see
is the ‘archiving’ function moved from the modality to the servers archive. This will save
the technologist’s time in not having to manually store exams to tape, CD, or whatever
media is used. As of 06/18/07, however, we do not have a full disaster recovery
mechanism for our archived exams, so continuing to do modality based archiving of
exams is necessary.

Item 4 allows the modality to query the PACS server for prior studies to use as
comparisons at the modality (to mimic prior studies as closely as is desired).

Item 5 allows the modality to print to our DICOM print servers.

Item 6 specifically states that it is the vendor’s responsibility to make their equipment
work with our information systems (PACS/RIS). This is to prevent us from being caught
in the middle of a finger pointing session. If they can’t get it to work, we will not accept
it. It also requires the vendor to include any licensing that is required by the system the
modality needs to connect to. There is a DICOM license fee of $1500 ($4500 if non-GE)
to connect to PACS for any new modality, and a $1000 SQL license if a worklist is
required (these are only sold in a 5 pack by GE). If the modality needs to connect to other
devices, there may be licensing fees for that as well. We should know these things, but
we want it to be the vendor’s responsibility to make sure all is taken care of and included
in the bid.

Item 7 is extremely important. IHE is a concerted push to enable information systems
integration that is being sponsored by RSNA, HIMSS and SIIM, as well as many
international groups. This started in the Radiology realm, but the idea is to get other
groups involved to Integrate the Healthcare Environment. It is very important that we, the
customer, ensure that the vendors move down this path. If we don’t require it, they won’t
do it. IHE has been evolving and growing over the last 4-7 years, and has been prevalent
at RSNA and HIMSS for the last 3 years. Although there is much work to be done, there
are a lot of ‘profiles’ that are currently embodied in the framework. Now that the HIPAA
privacy and security rules are in effect, we must have the ability to audit for security
events, and to provide access control at the device. Not having these capabilities is simply
not an option anymore.

Item 8 allows for the modality itself to store DICOM and jpg images that can be
transferred to pc. Utilization of such will fall under HIPAA guidelines, so be aware that
you will need a way to document the transfer of any Identifiable Healthcare Information.
If all identifiers are stripped, there should be no problem, but auditing is still necessary.

Shared By:
Description: DICOM Requirements for Modality Bid Specs Ris